把它做成生产功能之前，需要先拆开协议事实、产品承诺和运行成本，三者混在一起很容易得到错误结论。 ICE restart 保留现有 PeerConnection 和轨道关系，只更新 ICE 凭据并重新检查路径；对象已关闭、协商状态损坏或应用身份已失效时，继续复用反而会把旧状态带进新会话。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
落地方案的关键部件
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 先依据 connectionState、iceConnectionState 和选中候选对判断是路径失效还是整个会话失效。
- 为每次 restart 生成新的协商版本，答案、候选和超时都只能修改对应版本。
- DataChannel 与功能任务单独对账；底层恢复不等于文件、聊天或共享任务自动继续。
可维护的策略是先尝试一次有版本隔离的 ICE restart，确认会话对象仍健康；若协商或身份边界已经破坏，就用新会话重建，而不是无限修补旧对象。
别让错误假设进入生产
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 双方同时 restart 产生 offer 冲突，旧 answer 晚到后覆盖已经成功的新路径。
- 连接对象已进入 closed 或 failed 终态仍反复 restart，界面长期停在正在恢复。
- 用户已经停止重连，但 online 事件又触发 restart，违背明确的停止意图。
发布闸门应该检查什么
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 在 Wi-Fi 切蜂窝、VPN 开关和路由器重拨场景分别记录恢复时间与最终候选对。
- 让双方同一毫秒检测失败并发起恢复，确认只留下一个有效协商版本。
- 在 restart 中途关闭连接并点击停止，确认所有定时器、候选和自动唤醒都被隔离。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。