客户打来电话，第一句通常是：“我们场馆千兆宽带，为什么直播还卡？”我一般不直接反驳，先问一句：是主播画面自己卡，还是观众端卡？是全程卡，还是偶尔卡一下？这几个问题问完，八成的“带宽背锅案”就翻案了。做了这么多年直播执行，我越来越觉得，卡顿是个被严重误读的词——它根本不是一种故障，而是一类故障的统称。
先把“卡”分个类，再谈怎么治
我们内部把直播里的“卡”分成三种。第一种叫编码卡，是推流端这台机器自己掉帧，画面从源头就不顺；第二种叫网络卡，推流路上丢包或者抖动，包到不了服务器；第三种叫播放卡，服务器发出去了，但观众那边的CDN节点或者手机网不行。三种卡长得很像，观众都觉得“直播卡了”，但修法完全不一样。有回在石家庄一场发布会，客户咬定是网络问题，我们调出导播台本地录制回放，发现本地画面就已经一顿一顿的——那是编码卡，跟场馆网络半毛钱关系没有。
编码端：码率不是越高越好，关键帧才是隐形杀手
很多人觉得，卡是因为码率给低了，于是拼命往上加。其实在同样的带宽下，码率越高，对网络和编码器的压力越大，反而更容易卡。我们常规一场会议直播，1080p 把码率压在 3500–4500kbps 就够清楚，再高纯属浪费。真正容易被忽视的是关键帧间隔（GOP）。关键帧间隔设太长，观众切入直播时要等下一个关键帧才能出画，体感就是“进来黑屏好几秒”；设太短又吃带宽。我们一般把 GOP 控制在 2 秒左右，兼顾切流速度和流畅度。
还有编码档位。我们见过客户用软件编码硬扛 4 路机位，CPU 直接跑满，画面开始掉帧。这种我们用硬件编码器（比如插卡的推流盒）接管，CPU 占用立刻下来，卡顿消失。所以编码卡的第一现场往往不是“网”，是“机器扛不住”。
网络端：上行带宽管够，抖动却能把你坑死
带宽和抖动是两件事。带宽决定你能传多宽的水管，抖动决定水流稳不稳。一场直播要稳定推流，我们更看重上行是否平稳，而不是峰值有多高。医院、展馆的公用 WiFi 我们基本不碰，负载一高就抖。稳定的方案是 5G 聚合加有线专线热备：三网并发把抖动摊平，单条链路掉了对画面没感知。我们实测过，聚合后上行稳定在 50Mbps 以上，抖动控制在毫秒级，比单根千兆宽带靠谱得多。
这里有个坑：专线也不是万能。专线稳的是带宽，稳不了“最后一公里”的抖动，尤其跨运营商、跨省的时候。所以我们对延迟敏感的场景（远程手术指导、互动访谈）必上 SRT 或 WebRTC，靠协议本身的纠错和重传兜住抖动，而不是光靠带宽硬抗。
推流协议：RTMP、SRT、WebRTC 到底怎么选
这是客户问得最多的问题，我给个速查表。RTMP 最通用，延迟大概 3–8 秒，适合对实时性没要求的发布会、年会；SRT 抗丢包强，延迟能压到 1 秒以内，适合跨省、网络不稳定的场景；WebRTC 延迟最低，能到 500 毫秒级，适合互动、连线和远程指导，但架设复杂、成本高。普通活动用 RTMP 足够，真要“低延迟”却还抱着 RTMP 不放，观众那边永远慢半拍。我们一般按“观众要不要实时互动”来定协议，不按设备档次定。
播放端：别忘了对面的 CDN 和 DNS
推流再稳，观众端也可能卡，因为中间隔着 CDN。节点覆盖差、回源慢、DNS 解析绕路，都能让画面卡住。我们的做法是发布前用真实地区的网络测一遍播放延迟，挑覆盖好的 CDN 节点，必要时给客户开多节点。还有个常被忽略的点：观众连的是 2.4G WiFi 还是 5G，手机型号老不老。这些我们控制不了，但能在直播须知里提醒客户“用流量或 5G WiFi 看更稳”。
我们的现场排查清单（按顺序来）
每场直播前，执行团队会按这张单子走一遍：一、本地导播台录回放，确认编码端不卡；二、推流端跑 speedtest，看上行和抖动；三、换协议测延迟，RTMP 不够就上 SRT；四、观众端用三地网络实测播放；五、准备热备链路，单线断了秒切。这套流程跑下来，卡顿投诉基本归零。说白了，直播稳不稳，七分在准备，三分在设备。
所以下次再有人跟你说“直播卡就是带宽不够”，你可以把这篇文章转给他。真正的卡顿，很少是带宽的锅，多半是编码、抖动和协议这三样里某一个没排到。准备越细，现场越稳——这是我们排过一百多场之后，最想告诉甲方的一句话。
