一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 URL 表示用户希望看的位置，持久任务表示可能继续的工作，两者都不是当前事实。初始化应先验证路由是否合法，再加载任务和连接，最后决定展示恢复、结束还是重新授权。
前端架构的核心不是目录层级，而是状态由谁拥有、事件能否重复执行、旧异步结果如何失效，以及卸载后监听器和资源是否真正归零。
设计时必须回答的问题
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 公开路由只保存功能标签和非敏感筛选，连接码、令牌和文件名不进 URL。
- 恢复协调器按任务 ID 核对终态与远端状态，页面组件不自行启动重连。
- 无效或无权限深链接回到最近可用页面并解释原因，而非空白或死循环。
刷新恢复是一次数据对账，不是把 localStorage 原样画回去。URL、权限、任务终态和远端事实都通过后，页面才进入可继续状态。
边界情况不是附加项
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 路由 watcher 与恢复 store 同时跳转，页面在两个标签间快速闪烁。
- 历史 URL 包含已撤销设备 ID，刷新后自动向陌生设备发起连接。
- 完成任务仍在持久列表，深链接打开后 UI 错误显示正在传输。
用证据确认它真的可用
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 从每个功能标签和任务阶段刷新，验证最终路由、焦点和连接行为。
- 打开过期、撤销和篡改深链接，确认没有敏感值进入日志或 canonical。
- 让路由恢复与远端上线同时发生，断言只启动一次协调流程。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。