一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 同一 Wi-Fi 名称不保证设备二层可达，访客网络常启用 client isolation。浏览器还可能用 mDNS 隐藏 host IP，需要双方解析与路由支持。
网络诊断必须区分观察事实与推断结论。候选类型、选中路径和阶段耗时可以证明连接过程，完整 IP 或一次探测结果既不必要，也不足以代表真实可达性。
设计时必须回答的问题
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 记录但不上传敏感地址的 candidate type、protocol 与选中 pair；本地诊断检查子网、mDNS 解析、AP 隔离和 host/srflx 连通。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“明明在同一局域网，WebRTC 为什么仍然走 TURN”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 看到同一公网 IP 就判断同 LAN 会被 CGNAT 或办公 NAT 误导；强制 host candidate 又可能暴露接口地址且仍被防火墙阻断。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
用证据确认它真的可用
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 在家庭、访客 AP、企业 Wi-Fi、有线加无线和 IPv6-only LAN 中比较候选与选中路径，给出用户可操作诊断结论。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。