好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 负载均衡切到 green 只影响新连接，blue 的存量 WebSocket 可持续数小时。两版本必须在整个排空期间共享兼容消息与权威状态。
发布方案必须可复现、可观察并可回退，且回退要包含配置和数据兼容性。健康检查只证明进程存活，核心路由、依赖和后台任务还需单独验收。
先定义系统契约
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 先影子验证 green，再按 1/10/50/100% 接新连接；blue 宣布带抖动迁移并设最长排空时间，目录支持跨色路由。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“实时服务蓝绿发布：长连接和新旧协议怎么一起迁”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 只看 HTTP 健康就切 100% 会漏掉 WebSocket 与 TURN 凭据错误；blue 立即杀掉会制造重连风暴和任务中断。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
如何逐条验证契约
发布闸门应包含确定性回归、随机时序探索和真实浏览器组合。发现一次失败后保存 seed 与状态轨迹，让它永久成为可重放用例。
- 在连接、聊天、文件和屏幕任务进行中分阶段切流并回退，核对跨色消息、重复副作用、排空时间和连接 SLO。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。