做在线教育平台，视频永远是绕不开的核心底座。这两年我陆陆续续帮几家教育机构搭过线上授课系统，从最早的单机录制课点播，到后来的大班直播课、小班互动课，再到最近在研究的WebRTC低延迟连麦辅讲，一路踩坑踩过来，今天就把这套基于EasyDSS视频直播、RTMP推流、点播VOD、视频转码再加WebRTC技术构建的在线教育视频技术底座，完整拆给大家看看。

这个底座能解决什么问题？说白了就三件事： 老师端的画面怎么能稳定推到服务器 ， 学生端怎么能快速看到画面 ， 以及整节课的内容怎么能录下来、存下来、剪出来、再高效地分发出去 。如果你正打算自建一套在线教育视频系统，或者你已经在用各种云服务但想搞明白底层到底在跑什么，这篇文章会非常值得你看下去。我会尽量把协议选型、编码参数、服务端配置、常见坑位这些底层的东西讲透，让你拿去就能用，而不是停在概念层面空谈。

1. 在线教育视频底座的架构思路与选型考量

1.1 为什么是EasyDSS而不是直接买云点播

很多刚起步的机构会纠结，要不要直接用云厂商的直播和点播服务。说实话，如果预算充足、团队又小，直接用云服务确实省事。但一旦你有这些需求——比如讲师课件要实时合成画面、需要私有化部署到校园内网、想要自己掌控录制文件的存储和转码策略、或者对课时数据要做深度二次分析——云服务的封闭性就会开始让你难受。EasyDSS这类的流媒体服务器最大的价值，是它把 流接入、协议转换、转码、录制、存储、分发 这些核心能力都开放出来，你可以拿它当一个可以定制的视频中台，而不是一个只能上传和播放的黑盒。

以我最近给一家成人职业技能培训机构做的方案为例，他们的公开课频率高，一节90分钟的直播课结束后，半个小时之内就要出回放。以前用云点播，上传转码加生效，通常要等两三个小时甚至更久。换成EasyDSS做本地录制加本地转码之后，直播一结束录制文件立刻落盘，转码任务直接进内置转码队列， 多码率输出完了再同步到存储节点 ，回放生成时间压缩到了20分钟以内。这个提升对教研运营团队来说体感非常明显。

另一个关键点是成本结构。在线教育的视频流量有明显的"潮汐效应"——晚高峰和周末是集中上课时间，白天和深夜基本没什么流量。云厂商按带宽峰值计费，高峰期一上去账单就绷不住。EasyDSS这种自建方案是按服务器实际容量来跑，流量再大也只是服务器的并发上限问题，不会出现"什么都没干但费用飙升"的情况。当然自建有自建的运维成本，所以我的建议是， 中小型机构可以先拿EasyDSS搭一套标准底座，核心流量自己扛，突发的大规模公开课再临时租用云端资源做扩展 ，两头兼顾。

1.2 RTMP推流在当前直播链路里的位置

说RTMP之前先聊个误区，很多人以为RTMP是"老掉牙"的协议，新项目不应该再用。其实完全不是这样。RTMP在 推流上行链路上 ，到今天依然是兼容性最好、稳定性最可靠的选择。OBS、各种Android/iOS端的直播SDK，几乎全都原生支持RTMP推流；大型云厂商的直播接入标准和EasyDSS这类私有化流媒体服务器的推流接入，也全都以RTMP为默认首选。

为什么是这个局面？因为RTMP基于TCP，传输可靠，穿透性也不错。虽然有延迟（协议本身会导致几秒到十几秒不等的延迟），但对于 标准直播推拉流场景 ——老师端推画面到服务器，学生端通过HLS或HTTP-FLV拉流观看——这个延迟级别完全可接受。在线教育里，学生看老师讲课和课件，大部分情况下需要的是"接近于实时"而不是"必须严格实时"。线上大班课允许3到5秒的延迟，反正大家不互动，或者只需要文字聊天互动，这完全够用。

在我实际配置的架构里，老师的推流链路是这样的：OBS或定制推流端使用RTMP协议连接EasyDSS的 1935端口 ，将视频流推送到指定应用名和流名。EasyDSS收到RTMP流之后，再把它转成其他协议用于分发。所以这里的RTMP扮演的，是整个链路里从老师电脑到服务器这一段最稳的"搬运工"。了解了这一点，你就能明白为什么我们在讨论在线教育视频底座时，总是先把RTMP推流链路搞定，再做其他事情。

1.3 WebRTC不是来取代RTMP的，是来补短板的

看热搜词里经常有人对比WebRTC和RTMP，好像这俩是生死对手。其实在在线教育场景里，它们是明确的分工关系。 RTMP负责高并发、大班课、内容分发 ， WebRTC负责低延迟、双向互动、小班课和连麦辅导 。

WebRTC走的是UDP，基于SRTP做媒体传输，端到端延迟可以控制在500毫秒以内。这个能力对小班互动课是刚需——如果两个学生连麦回答问题还要等3秒才听到对方说话，那课堂根本没法进行。我现在的做法是：一堂课如果人数在二三十人以内，且需要学生和老师实时音视频互动，就走WebRTC通道；如果是一两百人以上的公开课，就回落到RTMP推流加多协议分发的模式，牺牲一点实时性换来稳定性和并发能力。

这里需要强调一个实操点： WebRTC并不是一个像RTMP那样"推一个流地址就能拉流"的简单协议 。它需要信令服务器做媒体协商，需要STUN/TURN服务器做NAT穿透，服务端还必须有SFU（选择性转发单元）来处理多路流的混流和转发。好在EasyDSS新版本已经集成了WebRTC相关的网关能力，大大降低了这块的搭建门槛。我后面会专门开一节讲WebRTC在在线教育里的落地细节。

1.4 VOD点播与转码：把课程变成可销售的资产

直播是一时的，点播才是长期资产。每节直播课录下来，经过剪辑、转码、打点、封面设置，就变成了一节可以在商城上架的标准课程。这个环节里，VOD（视频点播）和视频转码承担了核心职责。

EasyDSS内置的VOD模块，可以把录制下来的原始视频文件管理起来，并且通过内置的转码服务输出多码率版本。为什么要多码率？因为学生端的网络差异太大了。有的学生家里是千兆光纤，有的学生在地铁上拿手机流量看课。如果只有一个1080P的码率，网络差的学生就会一直卡顿，然后流失。一般我们会同时输出三档： 1080P（高清）用于PC和网络好的用户，720P（标清）用于移动端和一般网络，480P（流畅）用于弱网环境 。播放器根据当前带宽自动切换。

转码环节还有一个对教育场景特别重要的点： 课件文字的可读性 。教育视频不同于娱乐视频，PPT上面的文字如果压缩得太狠，直接就糊了。所以在做转码参数设定时，视频的码率不能压得太低，编码参数也要选得更保守一点。我一般会把视频的CRF值控制在23以下（x264编码），保证文字的锐利度。

2. 核心细节解析与实操要点

2.1 直播接入层：从设备到服务器的推流细节

先来看这个场景。一位老师打开电脑上的OBS，准备开始一堂直播课。在OBS里，他要做的事情是配置推流地址和推流密钥，格式一般是 rtmp://你的服务器地址:1935/live/teacher001 。这里的 /live 是应用名， teacher001 是流名称。应用名和流名可以根据你的业务来定义，比如不同的课程分类就用不同的应用名，不同的老师就用不同的流名。

很多教程不会告诉你， 流名称的设计其实会直接影响你后续的数据统计和录制文件管理 。我建议把流名设计成"老师ID_课程ID_场次ID"的格式，比如 T1024_C5566_20241011 ，这样录制文件生成之后，能直接对应到具体的课程和老师，做后续检索和补录非常方便。如果只是随便写一个 stream1 之类的名字，等到课程量大了之后，排查问题会痛苦到崩溃。

推流端还有一个容易被忽略的重要参数是 关键帧间隔（GOP） 。默认情况下，OBS的关键帧间隔可能设置在2秒，但实际上在线教育场景建议设置为1秒或2秒，并且 必须保证推流端的关键帧间隔与服务器转码和录制策略匹配 。关键帧间隔太大，会导致学生端在进入直播时等待关键帧的时间变长，表现就是"黑屏好几秒才出画面"。关键帧间隔太小，则会增加编码开销，浪费CPU。我自己一般设置1到2秒，实测下来首屏加载速度和编码开销能达到一个均衡。

音频方面，老师在教室或家里做直播，环境噪声音量差异很大。我建议推流端固定使用AAC编码，采样率44100Hz，双声道，码率128kbps。这是兼容性最好的一套参数，无论学生端是浏览器播放HTML5流、还是App内播放，都能正常出声。如果你用的是48kHz采样率，某些老版本的播放器会出现音频解码失败的问题，这个坑我踩过不止一次。

2.2 服务端接入：EasyDSS的流处理与协议转换

老师把流推到服务器之后，EasyDSS要做的第一件事是 收流 。收流进程从1935端口拿到RTMP流，这时候流在系统内部是一个原始的RTMP会话。接下来，EasyDSS会根据你的配置，把这个流同步进行以下几种处理： 协议转换成其他格式用于分发、直接录制到本地磁盘、送入转码队列做多码率处理 。

这里有一个典型的架构心法，协议转换是流媒体服务器的灵魂。同样一路RTMP推流，学生端有的浏览器只支持HLS播放，有的用的是兼容HTTP-FLV的播放器，有的是微信小程序里用特定live-player标签拉流。一个能打的流媒体服务器，必须能把一路RTMP流同时输出成HLS、HTTP-FLV、WebRTC等不同格式让学生端各取所需。EasyDSS在这方面做得比较顺手，这些协议转换动作在后台都是自动完成的，你要做的只是在配置里选择"需要开启哪些协议输出"。

我第一套自建系统的时候，把端到端的协议链路想得太简单了，觉得只要推流端和播放端都支持RTMP就万事大吉。但实际上浏览器原生播放是不支持RTMP的，你必须在服务端把流转换成HTTP-FLV或HLS。这个认知转变很关键。可以说， 理解了流媒体服务器的协议转换逻辑，你才真正理解了在线教育视频底座的运行方式 。

2.3 视频编码与转码参数怎么选：兼顾画质、体积与兼容性

转码，本质上是在画面质量、文件体积和设备兼容性之间做平衡。教育视频和娱乐视频在转码策略上的最大区别是： 教育视频对文字区域的清晰度要求极高 。

先说编码器的选择。目前主流是H.264，兼容性最好，从老旧的Android手机到最新的iPhone，从PC浏览器到智能电视，几乎全都能硬解。H.265（HEVC）确实能在同等画质下减少约50%的体积，但在线教育场景里，很多老设备的浏览器播放器根本解不了H.265，兼容性隐患太大。所以我建议，标准课程一律输出H.264编码，只有在做存储归档时才保留一路H.265的精简版本，用于节约存储成本。

再说码率怎么定。以一堂1080P30帧的课程为例，我的经验参数是： 视频码率2500kbps到3500kbps，音频码率128kbps，GOP设置为2秒，帧率30fps，编码预设用medium或slow 。这个码率范围下，PPT文字的清晰度基本能保证，同时单节课90分钟的文件体积能控制在2GB以内。如果你要再用480P档位做低码率分发，视频码率压到800kbps左右就差不多了，再低文字就会糊得没法看。

这里还得提一个很多人忽略的参数， Profile。我们一般用H.264 High Profile，但如果你发现某些低端安卓机上视频花屏或绿屏，可以降级到Main Profile试试 。兼容性问题上，宁可损失一点点压缩效率，也不能让一部分学生看不了。

2.4 录制与存储规划：课程回放怎么沉淀

直播结束之后，录制文件的安全和存储规划就变得重要起来。EasyDSS支持的录制格式一般是FLV和MP4两种。FLV录制几乎不会因为异常中断而损坏文件，适合直播过程中的实时录制；MP4则更适合直接用于编辑和点播分发。所以我的推荐配置是： 直播过程中录制FLV原始流，直播结束后通过转码任务把它封装并转码成MP4多码率版本 。这样既保证了录制过程的可靠性，又拿到了适用于点播的标准文件格式。

存储方面，如果课程量不大（几百节以内），单机本地磁盘就够了；如果课程量大或者有高可用需求，我建议把录制目录挂载到NAS或对象存储上。EasyDSS的存储配置支持自定义路径，你可以直接把录制目录指到NFS挂载点或远程存储挂载目录。这里提醒一下，远程存储的写入速度直接影响到高并发直播时的录制稳定性。如果网络存储速度跟不上，直播流会缓冲甚至断流。所以预算允许的情况下，给录制存储上SSD或者万兆局域网，不要在这个地方省钱。

3. 实操过程与核心环节实现

3.1 从零搭建一套可用的在线教育视频底座的步骤

这套底座的搭建，核心分四步： 准备服务器环境、部署EasyDSS、配置直播应用与转码模板、接入播放器并验证全链路 。

第一步没什么好说的，一台Linux服务器，建议4核8G起步，带宽按业务量评估。如果只是内部测试，2核4G也能跑，但转码任务多的时候会比较吃力。第二步是拿一个EasyDSS的安装包，按官方文档完成部署，装好之后默认端口是10080，网页管理后台就直接通过这个端口访问。第三步是在管理后台创建应用——我会建一个 live 应用专门用于直播推流，再建一个 vod 目录用于点播文件管理。同时配置转码模板，把上面讲的四档码率预设好。第四步就是最关键的全链路验证：用OBS推流，用VLC或EasyPlayer验证播放。如果这两步通了，说明直播链路基本通了一半；再把录制打开，确认录制文件生成并出现在VOD列表里，至此视频底座的核心能力就齐了。

3.2 推流端配置实例：OBS和移动端怎么推

OBS推流配置非常直观。打开设置-直播，服务选择"自定义"，服务器填 rtmp://你的IP:1935/live ，串流密钥填 T1024_C5566_20241011 。然后视频输出设置里，视频比特率填空，注意这不是编码器的码率，OBS的"视频比特率"是给编码器设定的目标码率，填3000Kbps；音频比特率填128。再往下，输出-录像里选"标准"类型，格式选FLV或MP4，编码器选硬件（如果机器支持）。

移动端推流要分情况。Android端可以集成EasyDSS官方提供的RTMP推流SDK，也可以使用第三方推流SDK，配置方式一样，核心就三个参数：RTMP推流地址、推流分辨率、码率。iOS端注意需要在Info.plist中加入摄像头和麦克风权限描述，否则调用推流SDK时会直接崩溃或黑屏。

这里有一个很实用的小技巧：如果你在测试阶段没有真实摄像头设备，可以用OBS的"窗口采集"或"显示器采集"来模拟老师端画面。我在调通整套链路时，就是开着OBS抓取自己电脑屏幕来当测试信号的。这样在没有老师配合的情况下，也可以随时压测整套系统的稳定性。

3.3 播放端的选择：PC端、H5端和小程序端都怎么播

播放端的选型很大程度上决定了你要用哪种分发协议。PC端我个人最推荐用EasyPlayer这类支持多协议的播放器，它能根据服务端输出的能力自动选择协议。在测试阶段，直接用VLC也能验证HLS和RTMP流，但VLC对HTTP-FLV的支持比较弱，正式产品不推荐。

H5端浏览器播放有几个硬性条件。如果要做低延迟直播，浏览器播放HTTP-FLV通常要用flv.js，同时注意跨域问题。如果选择HLS播放，大部分现代浏览器原生支持HLS，但延迟会更高一些。在线教育里，H5端一般作为学生上课的主要入口，我一般优先用flv.js播放HTTP-FLV流，把延迟控制在3秒以内，体验明显好于HLS。

小程序端的播放是最有讲究的。微信小程序原生的 live-player 标签只支持RTMP和FLV格式，而且需要在小程序后台申请"直播能力"类目权限。如果类目没通过，后面所有播放逻辑都白搭。所以我给很多机构的建议是： 小程序端优先用live-player拉RTMP流或FLV流，如果要支持WebRTC拉流，目前主要依赖一些特殊处理或WebView内嵌H5播放器 ，这块限制比较多，需要你提前和平台的审核策略做匹配。

3.4 延迟到底怎么压：从推流到播放的每一层优化

在线教育场景中，"老师问一个问题，学生端3秒后才听到"是完全不可接受的。要压延迟，你必须从推流端到播放端逐层优化，任何一个环节出问题都会让延迟直接飙上去。

推流端，关键帧间隔尽量小——上一节已经强调过，设置1秒或2秒是合理选择。编码器里关闭"延迟优化"或类似功能，让编码器尽量实时输出。服务器端，选择HTTP-FLV作为默认分发协议，因为FLV的容器封装非常轻，延迟比HLS低很多。播放端，flv.js播放HTTP-FLV流时，设置 enableStashBuffer: false 可以大幅减少缓冲造成的延迟，但会偶尔出现卡顿，你需要根据自己的网络情况微调。

还有一个很多人不知道的技巧： 服务端开启"低延迟模式"或"实时模式"配置 。EasyDSS等流媒体服务器都有专门的延迟优化开关，开启之后会调整HTTP-FLV的分块发送策略，让数据能更快地到达客户端。我这里必须提醒， 延迟压得越低，对网络抖动就越敏感 。如果你把延迟压到1秒以内，公网环境下一定会频繁卡顿。合理的做法是把端到端延迟控制在2到3秒，这个范围内稳定性和体验都比较舒服。

4. WebRTC在在线教育互动场景的落地

4.1 WebRTC为什么能做到"真·实时"

WebRTC低延迟的核心在于它的传输方式。它默认使用UDP协议传输媒体数据，配合SRTP做加密、SVC做可伸缩编码、FEC做丢包恢复，整体设计思路就是奔着低延迟去走的。TCP协议在丢包时要重传，而UDP丢包后要么丢弃要么用前向纠错技术恢复，这天然就更适合实时通信。

在在线教育场景里，WebRTC主要用在 一对一、一对多的互动连麦 中。举个例子，一次小班课有8个学生，老师端画面和声音通过WebRTC推给服务端，服务端通过SFU单元把8路媒体流转发给其余的学生。SFU只做转发和选择性丢弃，不做混流与转码，所以服务器的CPU开销远小于MCU（多点控制单元）混流方案。这也是WebRTC能支撑多人互动的原因。

EasyDSS在新版本中集成WebRTC网关后，会把它作为其中一种对外分发协议，与RTMP、HLS并行。对使用者来说，体验上的差异是：学生端如果走WebRTC播放，延迟会低到几乎感觉不到。但对服务器来说，WebRTC并发带来的性能压力可比HLS点多得多，所以 WebRTC通道不能盲目地向所有学生全量开放，要有选择地用于互动场景 。

4.2 信令、STUN/TURN与部署注意点

WebRTC不是拿来就能用的，它依赖一个信令服务器来交换会话描述（SDP）和网络候选信息（ICE Candidate）。开源方案中，常用的信令服务器有Node.js的Socket.IO、PeerJS、或者基于Janus的网关。EasyDSS内置的WebRTC网关在一定程度上替你封装了信令的交互逻辑，但如果你要完全自主可控，还是得自己维护一套信令服务。

还有一个实际部署中特别容易踩坑的，是STUN/TURN服务器的配置。企业内部网络或者校园网络，很多学生处在NAT网关之后，UDP的P2P连接会穿透失败。这时候必须有TURN服务器做中继转发。我建议部署coturn作为TURN服务器，它稳定、开源、配置灵活。部署时注意防火墙必须放开TURN需要的UDP和TCP端口，否则学生端会一直处于"连接中"状态。测试阶段我尤其建议用一台独立的公网服务器部署coturn，方便排查网络问题。

4.3 Vue/小程序中的WebRTC接入方式

在开发侧，WebRTC在前端工程里用得越来越多，尤其是基于Vue的在线教育前端项目。Vue项目里接入WebRTC，通常先要拿到服务端返回的SDP和ICE信息，然后通过 RTCPeerConnection 建立连接。如果你用的是EasyDSS的WebRTC网关，它会提供一个标准播放地址（如 webrtc://你的服务器地址/live/流名 ），前端通过它封装好的JavaScript SDK可以直接拉流播放。SDK内部帮我们封装了SDP交换、ICE协商、媒体轨道处理等复杂逻辑，前端代码只需传入容器节点和播放地址即可。

我在Vue工程里接入时，踩过一个内存泄漏的坑。组件卸载时如果没有正确调用 pc.close() 和 track.stop() ，WebRTC的连接会一直挂在后台，时间长了页面越来越卡。正确的做法是在 beforeUnmount 或 onUnmounted 生命周期钩子里，显式地关闭所有 RTCPeerConnection 实例和媒体轨道。

小程序端的情况比较特殊，微信原生小程序对WebRTC的支持并不好。我自己跑通的方式是，在小程序里用 web-view 组件加载一个基于WebRTC的H5互动页面，在该页面内完成音视频通话，然后通过 postMessage 和小程序主体通信。这个方案虽然在体验上有一点割裂，但能绕过小程序原生能力的限制，是目前很多在线教育小程序做法里的常用妥协方案。

5. 常见问题与排查技巧实录

5.1 推流失败、推流断开怎么查

推流失败是大家在搭建第一天最容易碰到的问题。先说最常见的三种原因。

第一， 地址写错了或者端口不通 。这是低级错误但发生率极高。排查方法很简单：在服务器上执行 telnet 你的IP 1935 ，如果端口不通，先查云安全组和防火墙，把1935端口的TCP入方向规则加上。不用外部工具，本地就能定位。第二， 推流鉴权参数错误 。如果你在EasyDSS后台开启了推流鉴权，那么串流密钥必须和后台配置匹配，不然服务器会直接断开连接。第三， 带宽不够 ——如果推流端的网络上行带宽小于码率设定值，服务器端会频繁收到不完整的流，现象就是推流画面花屏、卡顿甚至断流。排查时去服务器管理后台看实时流的码率波动，如果码率上不去且波动剧烈，基本可以确定是上行带宽瓶颈。

5.2 拉流播放黑屏、卡顿和花屏

播放端的黑屏、卡顿和花屏，是另一个高频问题。黑屏通常和关键帧间隔有关。如果推流端的GOP设置过大，播放器起播时要等下一个关键帧才能显示出画面，表现就是"等了很久才出画面"甚至直接黑屏。把推流端的GOP改成1到2秒即可。

卡顿问题先看服务端的出流码率和播放端的下载带宽。如果服务器出流码率是3Mbps，而播放端网络只有1Mbps，那怎么调都会卡。这种情况下要依靠多码率转码，播放器自动切换到低码率档。花屏问题通常发生在RTMP转HLS的时序上，HLS切片如果和关键帧对齐不一致，播放器切到新切片时可能会花屏一下。这个问题的解法是让服务端开启 hls_segment_type=mpegts 配置，保证切片边界和关键帧对齐。

5.3 延迟过高与音画不同步的调整方向

延迟过高和音画不同步，这两个问题在在线教育场景里非常影响体验。延迟过高时，你首先要去查播放端用的协议。如果用的是HLS，那延迟天然就是5到10秒，这属于正常；想压延迟就得换HTTP-FLV或WebRTC。如果已经用了HTTP-FLV但延迟还是高，检查flv.js的缓冲设置，把 enableStashBuffer 设为false，把 autoCleanupSourceBuffer 设为true，通常能把延迟压到3秒以内。

音画不同步则要先分清是直播还是点播。直播场景下的音画不同步，多半是推流端的采集和编码问题，建议检查OBS的音频采样率和视频帧率是否设置正确——如果音频是44.1kHz而视频是30fps，在长时间直播中会因为时钟漂移产生累积性的不同步。点播场景下的音画不同步，则要先看转码模板里音频和视频的编码参数，某些快速预设会导致音视频时间戳漂移，可以用FFmpeg命令校验并修正时间戳。

5.4 我踩过的坑和给你的建议

这套系统我从零搭了一遍，经历了各种崩溃和各种调优，总结出几个值得写下来的经验。

第一， 做好全链路监控 。最简单的方法是在整个环节中装上日志系统：推流端记录推流日志，服务端查看接入日志和连接日志，播放端在浏览器里打开控制台看播放器事件。任何一步出了问题，都能快速定位到具体环节。如果不做监控，出了问题你根本不知道是老师网络不行、服务器转码慢了，还是学生端播放器有问题。

第二， 给录制文件设置周期性的清理策略 。老课程如果不及时归档或迁移，本地磁盘会被慢慢塞满。我建议把超过90天的原始录制文件迁移到冷存储，把点播用的MP4保留在热存储。磁盘满会导致录制写入失败，如果刚好赶上直播课，那这节课就直接没录上，非常麻烦。

第三， 一定要在真实网络环境测试，不要只在局域网里玩 。局域网延迟低、网络稳定，很多问题都被掩盖了。真实公网环境下，跨运营商的延迟、丢包和抖动，才是这种系统真正的考验。我见过太多机构在办公室调得妥妥的，结果上线一节课就卡成PPT。

第四， 不要在一开始就追求所有功能都要上 。如果你的核心痛点是直播稳定 + 快速回放，那就先把RTMP推流、EasyDSS录制、点播转码这几样做到极致。WebRTC互动、多协议分发这些，可以等第一版跑通之后再逐步加。系统是在迭代中长出来的，不是在第一天规划出来的。

最后再说一个小小的实操心得。我每次上线新课之前，都会让课程运营同事用OBS做一次完整模拟推流，录完一段15分钟的试课，然后检查录制文件是否正常、转码是否完成、回放是否可用。这个过程最多花20分钟，却能提前拦下90%的录制故障。在线教育平台的核心不是花哨的功能，而是每节课都能正常上、回放都能正常出。把这个"最笨的检查"坚持做下来，比任何花哨的技术方案都管用。