上个月连着跑了三场跨院手术指导，两场在省会三甲和地市医院之间，一场是三甲对县域。说实在的，出发前客户只丢了一句“要清楚、别卡”，没提协议。等我们到了现场，才意识到跨院这根线，选 SRT 还是 WebRTC，直接决定了屏幕那头的大夫能不能真的参与进来，而不是干看着。这事儿外表看差不多，真干起来完全是两本账。
两条路，解决的问题不一样
SRT 这套我们一般用在“信号要先扛一段不可靠公网”的场景。它把数据打包成能纠错的小包，路上丢了一部分，接收端还能拼回来，画面不会立刻花。我们在省对地市的专线加公网混合段用得最多，延迟能压到七八百毫秒，抖动也还能看。但 SRT 是单向流为主，想做双向对讲，得自己再叠一路音频回来，工程上麻烦点。那场三甲对县域，两地隔着两百多公里，县医院那端是新上的专线，卫生院那端靠的是普通商务宽带，我们就是拿 SRT 把主干画面稳稳传过去，抖动硬控制在正负四十毫秒以内。
WebRTC 相反，它生来就是双向低延迟的，我们测下来端到端经常能到三四百毫秒甚至更低，省三甲专家开口，地市大夫几乎能接上话。但它对网络质量要求狠——一旦公网抖动，它会优先保实时，结果就是画面掉帧、糊一下。所以纯 WebRTC 我们只在两端都有干净专线、或者现场有聚合路由兜底时才敢上。
延迟不是唯一指标
客户老问“能不能更低”，但跨院手术指导里，我更在意“稳不稳”和“对得上不对得上”。有场我们 WebRTC 压到了 300 毫秒，可地市那边的防火墙夜里策略一变，链路半分钟抖了三次，专家那句“往左一点”传到时手已经动了。后来换成 SRT 主路加一路独立音频对讲，整体延迟高到 700 毫秒，但整场没断过，指导反而顺了。屏幕那头的参与感，从来不是毫秒数堆出来的，是“全程没掉线”堆出来的。
我们的默认打法
现在跨院一般这么配：主干用 SRT 传手术画面，保稳定；双向语音单独走一条带 QoS 的链路，保对讲；两端各放一台四卡聚合路由器，把三家运营商的卡绑一起，公网抖了自动切到另一张。延迟写在合同里不写极限值，写“可预期区间”。协议选型影响的不只是体验，还有账——WebRTC 省事但逼着两端上专线，SRT 更皮实但要对讲另搭，预算和稳定性得一起算。
所以下次有人跟你说跨院直播要零延迟，先反问一句：你这段线，两端网络干净吗？指导是单向观摩还是双向参与？答案不同，协议选型天差地别。
