工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 至少一次投递环境中重复是正常现象。幂等处理需要保存命令的业务结果，而不只是短暂记住某个 WebSocket 帧已经出现。
实时后端必须在身份、顺序、背压和断线恢复之间给出一致语义。每条消息都要知道属于哪个会话版本、能否重放以及慢消费者达到上限后如何退出。
工程边界与取舍
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 客户端为一次用户意图生成稳定 commandId；服务端以主体、会话与 commandId 作为键，原子写入结果并向重复请求返回同一响应。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“信令命令幂等化：重复 Offer、Accept 和 Cancel 只能生效一次”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
生产问题往往发生在两个正确动作同时到达时。需要逐条检查迟到消息、重复执行、资源耗尽和版本交叉，而不是只补当前堆栈显示的那一行。
- 只在进程内 Set 去重会在重启后失效；只按 payload 哈希又会错误合并用户确实连续发送的两条相同聊天消息。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
把测试跑成闭环
发布闸门应包含确定性回归、随机时序探索和真实浏览器组合。发现一次失败后保存 seed 与状态轨迹，让它永久成为可重放用例。
- 重复、乱序发送同一 Accept 一百次并在中途重启信令服务，验证只建立一个会话、只通知一次且响应内容一致。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。