一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 离线 shell 的目标是应用可理解且可恢复，不是伪造完整功能。它可以展示历史与待传文件，但不能把缓存 presence 当作当前在线。
离线体验必须诚实区分本地可用、等待同步和服务端已确认。缓存版本、命令队列和冲突解决要一起设计，否则重新联网只会放大旧操作与新事实的冲突。
设计时必须回答的问题
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 核心 shell 有独立版本和离线 fallback，启动先标记 connectivity unknown 再探测服务；本地数据带“最后更新”并与实时状态视觉区分。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“离线 Application Shell：能打开页面，也要诚实说明哪些不能做”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 缓存一份“已连接”DOM 会让用户以为共享仍在进行；离线页没有返回和重试则成为死胡同。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 没有背压或配额时，慢消费者会把内存、队列长度与尾延迟一起推高，最后拖累无关用户。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 从已连接、传输中、博客和设置四个页面断网刷新，验证 shell 启动、历史真实性、功能门控、重试与联网后一次性对账。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。