1.1 为什么选 TRTC：三种直播方案对比

接手这个项目时，机构负责人给我的需求只有一句话：“我们要一个老师能讲课、学生能举手连麦、课后还能看回放的直播课堂。”听起来简单，但这句话背后的技术选型足够我纠结一个礼拜。

机构是 10 人团队，K12 编程课，老师 6 位，同时开课最多 3 个班，每班 20 到 30 个学生。没有专职运维，预算敏感，工期要求一个月内上线。我先把市面上的路子归成三种：自建推流、用 TRTC 这类实时音视频云能力自建课堂、直接买 SaaS 课堂成品。三个方案拆成六个维度逐一对比，最后落在 TRTC 上。这一节把我当时的对比过程原样写出来，给后面做同样选型的人一个参考。

三个方案、六个维度的对比

需要说明的是，这张表是我按自家情况打的分，不是绝对结论。团队里要是有专职音视频工程师，自建推流的维护成本会显著下降；预算特别充裕、又没有定制需求的话，SaaS 成品其实是最省心的。问题的关键从来不是“哪个方案最好”，而是“哪个方案最匹配你手上的资源”。打分的时候我还特意问过机构里的两位主讲老师：他们对直播课堂最在意的两件事，一个是提问能不能听到回音，一个是屏幕共享卡不卡。这两条也算进了延迟和弱网两项的评分里，因为它们直接决定上课体验。

方案一：自建推流为什么第一个被否

自建推流是我最早认真考虑的路线：老师用推流软件把 RTMP 流推到自建的开源推流服务器，学生在网页里拉流播放。好处是协议成熟、开源工具齐全，服务器放一台云服务器就能跑起来，前期的固定成本看起来很低。

真正跑通原型之后我才发现两个硬伤。第一是延迟：常见的 HLS 播放协议延迟普遍在五到十秒，老师问一句“这段代码哪里报错了”，学生要隔好几秒才有反应，课堂节奏根本带不起来。要把延迟压下去就得换更低延迟的播放方案，工作量立刻翻倍。第二是互动：编程课的核心场景是老师看着学生的屏幕手把手调试代码，这需要双向音视频，而单向推流架构要做到这一点，等于要在自建系统里重新发明一遍连麦。

转码也是隐形大头。一个班 30 个学生同时拉流，服务器不想被带宽压垮就得做转码分发，转码机器的选型、扩容、半夜挂掉的排查，对一个没有专职运维的 10 人团队来说是灾难。综合算下来，这条路省下的云服务费，全变成了自己的人力消耗。还有一点容易被忽略：自建推流的“便宜”建立在带宽稳定的前提下，一旦遇到学生家里网络波动，卡顿率根本压不下来，而实时音视频云服务背后的弱网调度能力是自己短时间补不上的。我把原型跑了一周，卡顿率和延迟两张表摆出来之后，自己就先弃了这条路。

方案二：TRTC 自建课堂的得与失

TRTC（视频通信）把音视频房间、低延迟传输、弱网码率自适应这些底层能力做成了云服务，我在业务端集成 SDK，把“课堂”抽象成“房间”，把“老师和学生”抽象成“角色”，上层逻辑完全由自己控制。连麦、屏幕共享这些在自建方案里要掉头发的功能，在这里基本是现成的。

代价是课堂的业务逻辑全要自己写：举手连麦的信令、聊天室禁言、录制文件的管理与回放，一个都跑不掉。但反过来想，这恰恰也是优势——本书后续篇章会一步步把这些模块搭起来，每个环节都能按自己的教学场景定制。比如编程课要把代码编辑器嵌进课堂页面，把答题器、随堂练习的消息揉进聊天室，这些深度定制在成品课堂里几乎不可能做到。

计费方式也适合小机构：按时长计费，不用提前包机器。旺季多上课多付费，淡季没课的时候成本自然降下来，这部分我在 1.4 节会详细拆解。

云厂商兜底的不只是调度，还有持续迭代的客户端能力。我们 App 端和 Web 端都要能上课，自建方案要自己维护两套推流播放器，而 TRTC 的多端 SDK 覆盖了主流平台，我只需要关注业务逻辑。对独立开发者来说，这相当于把一个音视频团队的活儿外包了出去。

方案三：SaaS 课堂成品为什么没选

SaaS 课堂是最快上线的路：开通账号、配置课程，第二天就能开课。我花了一个下午试用了两家产品，结论是开课很快，但再往前一步都很难。界面是固定的，我想把机构自己的课件体系、代码评测结果嵌进课堂，只能通过它提供的有限接口；录播视频存在它的平台上，想迁出来做自己的回放门户也不方便。对一个把教学流程差异化当核心竞争力的机构来说，这些限制是致命的。

另外，SaaS 课堂普遍按座位或按月收费，班级规模一旦上去，长期费用并不比云服务自建低，而且这些费用里有一大半是为我用不到的功能买单的。数据归属也是个大问题：学生的随堂答题记录、老师的板书数据都锁在对方平台里，机构想拿来做教学分析，接口不全、导出受限。对一家想做长期教研积累的机构来说，这些数据比眼前省下的几天工期值钱得多。

试用的过程也不是走马观花。我按机构真实的上课流程做了三件事：开一班体验课让老师实际讲二十分钟、把一段往期课程视频传上去看回放页面、再模拟一次三十人并发进房。做完这三件事，成品课堂“好看但不够用”的判断就完全坐实了。选型这件事，原型验证比演示文档可靠一百倍，三个方案我都做过原型，只是自建和 SaaS 的原型只跑了一周，TRTC 的跑到了上线。

对比表之外的三个补充判断

六个维度的对比表之外，最终推动我下决定的还有三个表里不好量化的判断。第一是团队基因。机构里没有一个人做过音视频底层，但有两个会写业务后端的兼职开发。把人力投在业务逻辑上（课堂规则、互动玩法、教研数据）而不是音视频底层，是这个团队唯一正确的投资方向。

第二是迭代节奏。教育机构的产品节奏是跟着学期走的，每学期都要加新玩法：这学期要随堂测验，下学期要做编程对战。自建底座的迭代速度跟不上，SaaS 成品的开放程度跟不上，只有云能力加自研业务这条路，既能跟着学期快速变，又不用重新造轮子。

第三是生态预期。课堂平台不是孤岛，后面试接的 AI 语音转写、AI 助教、数据看板，都需要和音视频系统产生数据交互。用云服务的好处是这些能力天然在同一个生态里，接口和数据格式天然接近，集成成本比跨厂商拼接低得多。

回头看，这张对比表真正的价值不是让我选中了 TRTC，而是让我选中之后不后悔。后来项目遇到卡顿、遇到录制迁移、遇到成本上涨的时候，我把表翻出来重看一遍，五个维度的结论依然成立。选型时把理由写清楚，等于给未来的自己留了一份不动摇的依据。

结论：互动、定制与成本的三方平衡

最后选 TRTC 的理由可以压缩成三句话：课堂互动的延迟要求只有实时音视频能满足；教学场景的深度定制要求业务逻辑握在自己手里；小机构的现金流要求成本随用量弹性伸缩，而不是提前押一批服务器。三条叠加，自建推流输在互动，SaaS 输在定制，TRTC 是唯一同时顾及三者的方案。

补充一点：选型结果和我们最初的直觉其实是相反的。团队里有人觉得“云服务贵、自建便宜”，也有人觉得“直接买成品最快”。真正把五个维度量化之后，两个直觉都被推翻了。所以后来机构里再讨论技术选型，我都是先拉一张对比表，把每个人的顾虑写进维度里，再逐一打分，效率比空对空争论高得多。

正式动手前我还做了最后一件事：把选型结论写成一份一页文档，发给机构负责人和两位主讲老师，里面只有三部分内容——选了什么、为什么、什么情况下会推翻这个选择。负责人当天就批了，老师说看不出技术细节但“哪些是我们能自己改的”这一条让他放心。这份文档后来在遇到技术争议时被反复引用，省下的沟通成本远超写它花的一小时。

最后交代一下这一节之后怎么读。选型定了之后下一步就是摸清概念，下一节就是为你写的。

再多说一句心态方面的话：选型阶段最容易犯的错是“贪大”。我中途也动摇过，想用自建推流省钱、又想用 SaaS 省事，最后发现什么都想兼顾等于什么都做不好。承认团队只有这么多人力，把一件事做扎实，比什么都重要。

给小白机构的选型结论清单

如果不想看完整对比，下面这份清单可以直接照抄：

清单里没有“最好”的方案，只有“你团队能接住”的方案。每次有人找我聊直播选型，我都会先问三个问题：有没有音视频的人、工期多紧、以后要不要改——三个答案出来，方案基本就定了。

如果对房间、角色、流这些词还没有概念，直接看 1.2 节；如果想先看整体架构怎么落地，可以跳到 1.3 节。另外提醒一句，整个平台还需要云服务器、对象存储这些底座，这方面的基础选型我参考了 《腾讯云实战清单》 里的做法；后续课堂录音转写、AI 助教这类扩展能力，可以提前看看 《AI 语音转写实战》，我会在第 5 篇把这些能力接进来。

这里放一个当时我开通服务的入口：视频通信（TRTC）9.9 元起，价格以官网页面为准。

延伸阅读

• 《腾讯云实战清单》：云服务器与存储底座的选型实操
• 《AI 语音转写实战》：课堂录音转写与内容沉淀的思路
• 《AI 智能体开发实战》：AI 助教能力扩展的方向