RTC 推流有哪些典型应用场景？

团队想做一款带直播功能的产品，产品经理开口第一句常常是”我们要做直播”。但直播和直播之间差别极大：在线课堂要学生随时举手发言，秀场要主播和观众连麦 PK，电商大促只需要主播讲、十万人看。这些诉求落到技术上，第一个岔路口就是推流方式的选择，选错了，后面改架构的成本远超想象。

先分清”直播”这个词背后的三种诉求

“直播”在技术语境里被过度使用了。同一个词背后，业务诉求可以相差几个数量级：

强互动型。用户需要和主播、老师、同伴实时对话，延迟超过 500ms 对话就难受。
广播型。一个人讲、海量人听，观众不需要开口，延迟 3 秒也能接受。
混合型。一部分人实时互动，同时把内容广播给海量观众。

RTC 推流天然服务强互动和混合场景，因为它的协议栈、网络和计费都是为”双向实时”设计的。判断你的业务属于哪一型，比先选厂商重要得多。

强互动场景：RTC 推流的主场

这类场景的共同点是，推流方和拉流方地位对等，随时可能角色互换。

在线教学。1 对 1 和几十人的小班课里，学生要举手、发言、上台做题，师生进度必须一致。对推流的要求是低延迟加上流畅的多人并发，画质反而不是第一优先，课件和板书往往比人脸更关键。
连麦直播与 PK。秀场、语音社交里的核心玩法。主播与嘉宾之间各自推流、互为观众，延迟要低到双方能自然接话。这类场景还常把两路流在服务端混成一路，再做美颜、混响等前处理，对上行质量尤其敏感。
互动娱乐与协作。在线 KTV 要多人合唱精准对齐，互动播客要几十人同时在线说话，在线音乐教学要求 48kHz 采样率还原乐器音质。这些场景对音质的挑剔程度远高于画质。

它们的共性诉求可以概括为：端到端延迟百毫秒级、上行要稳（主播网不好是最常见的体验杀手）、多人音质要干净。

广播场景：不一定要用 RTC 推流

如果业务只需要”一人讲、万人听”，标准答案其实是 CDN 直播，用 RTMP 推到 CDN 分发即可，成本远低于 RTC。

但当广播内容本身是强时效的，就出现了中间地带。比如赛事直播，观众最在意的是”别被剧透”，延迟降到 1 秒内、支持 4K 高帧率才有意义；电商拍卖和秒杀需要所有用户在同一瞬间看到成交状态。这类场景如今有了专门的传输方案，业内通常叫超低延迟直播，延迟在 600ms-1000ms 区间，可视为”不需要双向互动的 RTC”。像即构(ZEGO)类似厂商都把它作为独立产品线提供。

场景类别	代表业务	延迟要求	双向互动	推荐推流链路
强互动	小班课、连麦 PK、KTV 合唱、互动播客	200ms-500ms	必须	RTC 推流
混合互动	大班课、秀场、电商直播、游戏直播	主播与嘉宾低延迟，观众可容忍秒级	主播群体内	RTC 连麦 + 旁路转推 CDN
超低延迟广播	赛事、拍卖、一起看	1s 内	无	低延迟直播通道
普通广播	发布会、企业年会	3s-10s 可接受	无	RTMP + CDN

混合场景：互动直播的标准架构

规模最大的商业场景集中在表格中间一行。一场电商大促，主播、助播、嘉宾在直播间内实时互动，百万级用户通过网页或小程序观看。技术上这拆成两段：互动段走 RTC 推流，保障连麦体验；广播段把主播的流旁路转推到 CDN，海量观众零成本涌入。主播推一路流，两个出口，两套链路，各取所长。

这种架构如今已经是行业标准做法，主流厂商都同时提供 RTC 与 CDN 旁路能力，且往往把”转推”做成一键式接口。以即构（ZEGO）这类同时具备 RTC、低延迟直播和 CDN 旁路的厂商为例，其 Express SDK 对直播场景内置了场景化预设，默认按 540p、20fps 的音画配置推流，并允许在推流成功后随时把流转推到第三方 CDN，目的就是让混合场景不用改架构、只调参数。