好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 现代浏览器降低了网页利用 WebRTC 枚举网卡地址进行指纹识别的能力。host candidate 可能包含以 .local 结尾的名称，真正解析和连通由浏览器网络栈处理，应用通常不需要也不应该反查明文 IP。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
先定义系统契约
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 候选解析器同时接受 IP 与 mDNS 主机名，并将“地址被保护”作为正常分类。
- 网络信息卡片只展示范围和候选类型，不承诺列出所有真实接口地址。
- 连接决策交给 ICE 检查；不要因应用层无法解析 .local 就删除 host candidate。
把 mDNS 当作浏览器隐私边界，而不是一个需要绕过的障碍；产品应描述可观察到的网络范围，同时让 ICE 完成真正的连通判断。
哪些情况会破坏契约
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 正则表达式只接受数字 IP，静默丢弃 mDNS 候选，导致同 LAN 也绕到 TURN。
- 调试页面把 mDNS 名称当 DNS 故障反复上报，制造大量无意义告警。
- 为了显示“网络指纹”调用外部 DNS 解析服务，反而把隐私地址暴露给第三方。
如何逐条验证契约
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 使用真实浏览器收集含 .local 的 SDP，确认解析、去重和候选统计完整。
- 同 LAN、访客隔离和跨网络分别连接，验证 mDNS 存在时 ICE 仍能正确选路。
- 检查日志与埋点，确保不记录可还原设备网络拓扑的名称或地址。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。