I3.03.2offline capability scope设计
离线可用范围需提前说明
别名: 离线能力 · 能做什么 · offline available · 离线功能边界
概念解释
人已经知道没网了，下一个问题是：我现在还能干什么。答案必须在动手之前给出，而不是点了保存才说「此功能需要网络」。离线可用范围（offline capability scope）是一份事先声明：可读哪些、可写哪些、哪些入口直接停用。范围含糊时，人会按在线模型继续，把失败理解成故障。
这条不解决「本地是否足够当权威副本」——那是架构选择。这里只要求：当前这次离线，界面把能力边界说清楚。
机制
离线把功能集切成三块：仍可用、降级可用、不可用。人默认按完整功能集规划下一步（回邮件、改表格、下单）。若边界不在规划之前出现，计划会建在空能力上，随后每一击都是一次预测误差。误差累积成「这个产品离线不能用」，即使其实还能读草稿、还能写待发送。
「提前」指的是意图形成时，不是请求发出时。入口还画成可点、点下去才禁用，是用一次失败来教学。教学发生在已经投入之后，代价记在信任上。把不可用的入口在离线模式里直接变成不可点并附原因，计划在眼动第一次扫过时就能改。
边界
只读浏览、字典、已下载媒体，范围几乎是「全部可读、全部不可写」，一句话就够，不必每个按钮旁注。范围随数据是否已缓存而变：没打开过的文档离线不可读，打开过的可以——这种动态范围必须当场说（「仅已打开的三份」），不能写死成「支持离线阅读」。紧急呼叫、支付、验证码这类法定或风控必须在线的能力，范围说明不能暗示「稍后再试就能成」，要说清现在不成。多人正在盯着的共享稿，离线可写但写的是尚未同步的私有副本，范围里要包含「别人暂时看不见」，否则可用被理解成已发布。
怎么落地
- 进入离线后，在指示旁给一句范围：「可阅读已下载项，编辑会在恢复后发送」或「仅可浏览，不能提交」。
- 不可用的主行动就地变为不可用，并写原因，不要留着可点外形。
- 范围随缓存变化时，用具体集合说话（「3 份已下载」），不用抽象承诺。
- 验证：断网后不要操作，先让人看五秒，问「现在能保存吗 / 能发消息吗 / 能看哪几篇」。答错或不敢答，就是范围没提前说明。再点一个本应不可用的入口：若直到提交失败才告知，说明写在了事后。