工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 ICE 的 consent 检查确认远端仍允许在选中候选对上接收流量；应用心跳确认功能协议仍在运行。两者失败含义不同：底层无 consent 必须停止发送，应用超时则可能只是主线程冻结。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
工程边界与取舍
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 把 PeerConnection 状态、最近数据活动和应用心跳组合成分层健康状态。
- 远端明确离开时立即传播终态，不等待底层 consent 超时才清理共享或文件任务。
- 单向网络恢复后重新验证会话版本与身份，旧地址迟到的数据不能复活任务。
连接健康不应压成一个布尔值。底层 consent、信令可达、应用心跳和功能会话各自有状态，产品才能既快速停止无效发送，又不误伤暂时冻结的页面。
生产环境会怎样出错
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 只看 WebSocket 在线就认为 P2P 健康，实际候选对已成为单向黑洞。
- 浏览器后台冻结心跳后立刻解除设备信任，把平台节流误判为恶意离开。
- 观看方消失后发送方仍编码屏幕数小时，浪费 CPU、带宽并泄露状态。
把测试跑成闭环
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 分别丢弃入站、出站和双向 UDP，观察底层状态与应用心跳如何收敛。
- 把观看方标签页冻结再恢复，确认不会误撤销信任且共享人数最终准确。
- 正常退出、断电和 NAT 超时分别测试资源释放时限与用户提示。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。