一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 单次失败正常，循环由有限时间内重复 connection-start → fail 且没有稳定窗口定义。监测器应位于统一状态机而不是每个 UI 组件。
可观测性应回答故障发生在哪个阶段、影响多少会话和是否仍在扩大。事件字段使用白名单与低基数维度，用户内容、密钥和完整网络身份不进入遥测。
设计时必须回答的问题
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 滑动 5 分钟计数 attempt、相同 errorClass 与最长稳定时间；超过阈值后打开本地 circuit，尊重用户关闭并提供一次手动重试。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“自动重连死循环监测：在用户反复看到连接条之前发现它”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 只按失败次数告警会把用户主动测试多个设备误判；关闭连接条仅隐藏 UI 而不写 stop intent 会让后台继续循环。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
用证据确认它真的可用
发布闸门应包含确定性回归、随机时序探索和真实浏览器组合。发现一次失败后保存 seed 与状态轨迹，让它永久成为可重放用例。
- 回放快速失败、短暂成功再失败、用户点 ×、网络恢复和多个对端，验证只熔断同一目标循环且指标在隐私预算内。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。