一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 应用层一次 send 的消息可能被 SCTP 分片，但对端与中间实现仍有最大消息限制。没有消息交织时，一个很大的低优先级消息会占住 association，使其他通道的控制消息也等待。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
设计时必须回答的问题
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 从远端 SDP 与浏览器能力得到协商上限，再取应用安全上限的较小值。
- 批量分块保持在保守范围，并通过窗口而不是超大单块提升吞吐。
- 控制通道保持小消息与高调度优先级，同时为不支持交织的实现保留降级。
安全分块不是找一个最大的数字，而是在协商上限内让吞吐、内存和控制延迟同时可控；窗口调度通常比放大单条消息更有效。
边界情况不是附加项
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 固定发送 128 KB，遇到协商上限 64 KB 的浏览器直接抛出异常。
- 看到 bufferedAmount 不高就继续放大块，忽略 association 级队头阻塞。
- 直连测试正常，TURN/TCP 的高 RTT 和重传使控制延迟突然放大。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 用不同 max-message-size SDP 夹具验证分块器绝不越过远端上限。
- 在 bulk 持续发送时测量取消、心跳和聊天的 p95 延迟，而不只看文件吞吐。
- 分别在支持与不支持消息交织的浏览器组合上跑高丢包 TURN/TCP 测试。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。