E6.14.4offline data completeness设计
长期离线可用性取决于本地数据的完整程度
别名: 离线能用多久 · local cache · 不完整离线
概念解释
断线几秒和断线几小时不是同一种产品状态。长期离线能不能继续工作，取决于这台设备上已经有多少、多新的数据：打开过的文档、缓存的列表、未下载的附件。提示需要把「现在还能做什么」限制在本地实际拥有的范围里，而不是用一张通用离线横幅暗示整个应用仍完整。可用性不是离线模式的开关，是缓存清单。
机制
短离线时，用户还在刚才那一屏上，工作记忆和屏幕上的像素都还在，本地缺什么不明显。时间一长，人会走到未曾打开的对象、搜索未缓存的集合、打开只在云端的附件。每一步都在拿一个不存在的本地副本。若界面仍用同一条「离线」覆盖所有这些尝试，失败会东一块西一块地冒出来，用户无法建立「离线边界」。把完整程度说出来——「仅已打开的 4 份可读」「搜索不可用」「附件需联网」——等于画出一张地图，人把任务收束在地图里，而不是在地图外撞墙。完整程度还会随时间变差：缓存过期、存储被系统清掉，长期离线的可用性是一条下降曲线，提示应跟着改，而不是第一小时和第十小时同一句话。
边界
刻意设计的离线优先应用（本地即主存储）完整程度高，提示应反过来强调「尚未同步」而不是「功能残缺」。受监管或加密的数据可能根本不允许完整缓存，长期离线在这些对象上应直接不可用，不要假装缺的只是网。多设备里「这台」的完整程度不等于「用户的」完整程度，文案要带设备或「本机」。只读的完整缓存和可写的完整缓存也不是同一档，能读不能写时要分开说。
怎么落地
- 离线提示按本地实际拥有列出能做 / 不能做，而不是一句「当前离线」。
- 打开未缓存对象时明确「本机没有这份」，不要用通用加载失败。
- 缓存被清或过期时更新那张能做清单；长时间离线后再次声明边界。
- 验证：只缓存一两个对象，断网一小时再四处点。用户若无法预判哪会打开哪会失败，完整程度就没被提示出来。