好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 设备身份长期稳定，但一次运行实例必须短命。服务端为设备签发当前 epoch，所有可变操作同时校验身份和 epoch 才能区分“同一用户的旧页面”。
实时后端必须在身份、顺序、背压和断线恢复之间给出一致语义。每条消息都要知道属于哪个会话版本、能否重放以及慢消费者达到上限后如何退出。
先定义系统契约
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 新实例注册时原子推进 epoch，并向旧连接发送 fenced 终态；数据层更新使用 WHERE epoch = expected，零行更新视为旧实例。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“会话 Fencing Token：把旧页面和旧连接挡在新会话之外”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 若只关闭旧 WebSocket 而不校验后续异步回调，旧 ICE 收集器和超时任务仍可能通过新连接发送过期命令。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
如何逐条验证契约
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 让旧页面在断网时积累命令，打开新页面完成连接后恢复旧网络，确认所有旧 epoch 写入被拒绝且不会弹出新提示。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。