工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 IPv6 可能给设备提供全球可路由地址，减少传统端口映射，但操作系统和路由器防火墙仍会阻止未经允许的入站流量。双栈设备还会同时收集 IPv4 与 IPv6 候选，最终路径取决于实际检查而非地址看起来更现代。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
工程边界与取舍
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 候选模型保存地址族与协议，并允许 IPv4、IPv6 候选对并行检查。
- TURN 域名发布 A 与 AAAA 记录前，确认服务监听、证书和中继地址都支持 IPv6。
- 路径 UI 只展示 IPv6 类型和范围，不显示完整临时地址或稳定接口标识。
IPv6 的正确策略是作为一等候选并行验证，而不是强制优先或完全禁用；所有地址解析、日志和中继部署都要真正具备双栈能力。
生产环境会怎样出错
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 代码用冒号分割 host:port，遇到方括号 IPv6 地址后端口解析完全错误。
- DNS 返回 AAAA 但服务器没有 IPv6 路由，客户端等待超时后才尝试 IPv4。
- 只按字符串比较地址去重，IPv6 压缩表示不同导致同一候选重复进入状态机。
把测试跑成闭环
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 在原生双栈、仅 IPv6+NAT64、仅 IPv4 和 IPv6 入站受限网络分别跑双浏览器测试。
- 验证 URL、日志脱敏、candidate 解析和 TURN 下发对方括号地址的处理。
- 模拟 AAAA 黑洞，确认连接不会因串行超时显著变慢且最终路径标记准确。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。