一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 同一对端的命令具有因果关系，跨对端的命令通常没有。按 peerId 分片能防止 accept 越过 connect，也不会让一个离线设备阻塞所有连接。
实时后端必须在身份、顺序、背压和断线恢复之间给出一致语义。每条消息都要知道属于哪个会话版本、能否重放以及慢消费者达到上限后如何退出。
设计时必须回答的问题
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 队列项携带 sessionEpoch、命令 ID 和截止时间；终态命令形成屏障，旧 epoch 的后续任务直接丢弃，空队列及时回收。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“每个对端一条有序命令队列：并发连接请求不再互相踩状态”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 用一把全局锁会造成队头阻塞；完全并行则可能先执行断开再完成接受，最终界面显示已连接而底层已关闭。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 让 A 同时连接 B、C，并对 B 快速执行接受、刷新、取消，断言 B 的事件严格有序而 C 的建立时间不受影响。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。