WebRTC为什么适合实时互动，却未必适合所有直播？

主播问一句、观众答一句，这类场景的等待时间会直接影响对话节奏。WebRTC 的价值首先体现在双向沟通，而非单纯把每场直播都压到最低延迟。

实时连接解决什么问题

W3C 的 WebRTC 标准为浏览器提供媒体和数据通信接口，支持音视频轨道和连接状态管理。实际部署还要处理网络地址转换、信令与服务器中转等问题。技术名词并不等于性能承诺：同样使用 WebRTC 的产品，在拥堵网络和不同设备上仍可能表现不同。

大规模观看需要另一套权衡

几个人连麦与几十万人同时观看，对服务器带宽和分发拓扑的要求差距很大。纯实时路径可能带来更高的边缘节点成本，也更敏感于丢包。面向大量观众的平台常把主播上行和观众下行分开设计，让互动少数人保持实时，普通观看采用更易缓存的分发方式。

画质自适应仍然重要

实时通话不能用长缓冲掩盖网络波动，编码器需要更快回应带宽变化。分层编码和可伸缩视频是改进方向，但是否可用取决于浏览器和平台实现。若用户只看普通直播，适度缓冲可能比持续抢低延迟带来更平稳的画面。

按场景选择指标

在线课堂可观察提问到回应的往返时间；赛事观看更关心画面与比分是否同步；购物直播还要考虑评论、商品信息和交易流程的时间关系。先定义‘用户感觉慢’的具体时刻，再决定协议和架构，才能避免为一个好看的延迟数字付出不必要的代价。

把方法放进真实场景

一场线上读书会只有八人，主持人希望大家随时插话；WebRTC 的双向通信特性很契合。活动结束后，如果录像面向数万人观看，使用易于缓存和分发的点播技术通常更自然。把同一场活动的实时交流与后续公开回看拆开设计，可以分别优化延迟和观看规模。技术选型跟随行为变化，而不是让一种协议从头用到尾。

在产品方案里，‘低延迟’最好写成可测量的目标：特定网络条件下，用户发问到对方听见需要多久；连接中断后恢复需要多久。只写‘实时’很难指导测试，也容易掩盖跨区域用户的差异。把百分位延迟和失败率一起看，会比展示一次理想演示更诚实。

WebRTC 是实时互动的重要基础，却不是覆盖所有视频业务的万能标签。方案是否合适，取决于观看规模和用户真正需要的响应速度。