做在线教育直播课堂，实时音视频方案怎么选？
内容提要
在线教育直播选型的关键是保证音视频流、课堂消息和教学信令三套实时数据的状态一致性。班型决定架构：大班课须分层，互动层用RTC、观看层用CDN。技术路线分自建、开源自建、商用SDK、全托管四类，多数团队适合商用SDK。选型应通过POC实测延迟、弱网和状态一致性等指标，而非只看文档参数。
延伸解读
三套实时数据的状态一致性是选型核心
文章指出，在线课堂同时运行音视频流、课堂消息和教学信令三套数据，其中教学信令要求最高，必须强一致、有序、幂等。选型时若只关注音视频SDK，忽略信令状态管理，容易出现麦位状态错乱等“产品bug”。因此，评估方案时需明确房间状态、麦位状态、权限状态由谁持有，是否一次写入多处读取，避免状态分叉。
班型决定架构，大班课必须分层
班型是技术架构的决定因素。1v1和小班课人数少，可全走RTC互通；大班课则必须分层：互动层用RTC保证低延迟，观看层用CDN分发承接高并发。选型时要警惕Demo阶段无法暴露的分层问题，务必询问“5000人同时观看时，讲师侧上行连接数是多少”，若等于观众数则方案不成立。
四条技术路线的适用边界与成本结构
自建、开源自建、商用SDK、全托管四条路线各有适用场景。自建门槛高，需长期养住音视频引擎、信令、教学工具、云端服务四条线，少于三条不建议自建。商用SDK交付效率高，适合大多数产品团队，且定制业务层与传输层解耦，不影响业务迭代。全托管则适合无技术团队、快速验证的场景。
POC验收：用真实场景测出确定性
选型最后一步是跑POC，建议留1-2周，用真实课件和真实设备测试。重点验收延迟、弱网表现与恢复、状态一致性边界场景、白板同步精度、录制产物完整性等。弱网测试要量化丢包、抖动、限带宽条件，观察首次进房、上下麦切换、重连三个时刻。方案是选出来的，但确定性是测出来的。
Q&A
在线教育直播课堂选型时，为什么不能只关注音视频SDK？
因为一节课同时运行三套实时数据：音视频流、课堂消息和教学信令，它们共用同一批用户和房间状态。SDK只解决音视频部分，如果课堂消息和教学信令的状态一致性没设计好，就会出现老师已同意上麦但学生还在转圈、学生已退出但麦位仍被占用等问题。
大班课和小班课的实时音视频架构有什么本质区别？
小班课人数少，全员走RTC互通即可；大班课必须分层：互动层（讲师和连麦学生）走RTC保证低延迟，观看层走CDN或超低延迟直播分发以承接万级并发。纯RTC全互通会导致讲师侧上行连接数等于观众数，成本和带宽无法承受。
自建实时音视频方案的真实门槛是什么？
自建的门槛不是开发难度，而是长期维护能力。一套生产级教育直播系统至少需要传输层、信令与状态层、教学工具层、云端服务层四条线的团队。如果这四条线中你有把握长期养住的不超过三条，就不建议自建。
在线课堂的延迟应该控制在多少毫秒？
没有统一数字，需按班型拆分：1v1和小班课连麦对延迟最敏感，要求最严；大班课互动层要求较高，观看层可放宽到千毫秒级。参考口径上，ZEGO的MSDN网络全球平均端到端延时为300ms。
如何有效测试实时音视频方案的抗弱网能力？
必须自己量化测试：用弱网模拟工具在真实设备上制造丢包、抖动、限带宽，重点观察首次进房、弱网中上下麦切换、网络恢复后的重连三个时刻。参考口径上，ZEGO在70%丢包环境下仍能保证流畅视觉体验。
教育直播课堂的POC验收应该重点检查哪些项？
建议用1-2周，以真实课件和真实设备跑完整课堂流程，重点验收：接入跑通时长、端到端延迟、弱网表现与恢复、多端一致性、白板同步精度、课件还原度、状态一致性边界场景、断线重连后的状态、录制产物完整性、低端设备表现、监控可用性、文档与支持。
商用SDK和全托管SaaS在在线教育场景下如何选择？
商用SDK适合绝大多数产品团队，提供模块化教学能力，交付效率高，且业务层可定制；全托管SaaS技术门槛极低、上线极短，但可控性最低，适合无技术团队、快速验证的场景。选择取决于团队技术能力和业务定制需求。
