做在线课程系统定制开发这些年我听过最多的需求开场白是同一句我们就想做个能看视频、能交作业的线上课平台。等需求评审那天对方拿出来的往往是从竞品截图里拼出来的几个页面。我不怪他们——在线教育看起来就是手机上看课但真正把一个一站式在线教育系统从零做到上线背后牵扯的远不止一个播放页面课程怎么上架、订单怎么支付、学习进度怎么记、直播和录播怎么衔接每一步都是独立的工程问题。这篇文章就把我这些年做在线课程系统的完整技术拆解写出来架构怎么定、课程和订单怎么建模、视频链路为什么是命门、定制开发里那些不写进合同的坑以及上线后真正该盯什么。适合准备自研平台的培训机构、正在做技术选型的团队负责人也想了解教育系统内幕的开发者。1. 一站式不是营销词是一张业务全景图很多客户跟我说一站式的时候心里的画面是学生能注册、能看课、能交作业。但在我这边的白板上一站式意味着整个业务闭环都能在这个平台上跑通——从课程生产、审核、上架到售卖、学习、考试、结业再到退款、数据分析、结算。这不是多了几个页面的事而是多了几套完全不同的业务系统。1.1 三次沟通后我画出的完整模块地图我第一次和客户对接时不喜欢急着聊页面而是让他们把日常业务流程从头到尾讲一遍。通常聊到第三次一张模块地图就能成型。按角色分一个完整的在线教育平台至少要覆盖下面这些模块角色端模块核心能力学员端账号体系注册登录、找回密码、第三方授权、账号安全学员端课程中心课程搜索、分类筛选、详情展示、试看、收藏学员端交易闭环下单、支付、优惠券、订单查询、申请退款学员端学习中心视频播放、课件下载、学习进度、续播、笔记学员端教学互动作业提交、考试答题、问答讨论、打卡、证书教师端教学后台章节管理、直播开课、作业批改、学情统计管理端运营后台课程审核上下架、公告、banner、用户管理管理端财务后台订单核对、退款处理、分账、发票、结算管理端数据后台转化率、完课率、留存、课程销售排行这张表落到数据库层面通常意味着三四十张核心表起步。你光看学员端账号体系这一个格子背后就有用户表、登录日志表、第三方授权绑定表、验证码记录表、用户扩展信息表。很多第一次做平台的团队就是低估了这个复杂度排期排到最后才发现光是一个学习中心就要占掉整个项目一半的时间。这里我要多说一句模块地图画出来之后一定要让客户逐行确认哪些是这次要做的。因为一站式是一句很危险的话——客户说这三个字的时候心里往往默认所有模块都是第一版就要但预算和排期根本撑不住。所以模块地图最大的价值不是展示规划能力而是把全都要模糊愿望变成一个可以逐项打勾的清单大家在此基础上谈优先级才有依据。1.2 定制开发与现成SaaS的边界有人会问市面上现成的一站式教育SaaS不少为什么还要定制开发我的态度是不是所有团队都适合定制但也不是所有需求都能被SaaS满足。这两件事的边界我一般在需求阶段就跟客户摊开聊清楚。如果业务模式是标准化的比如就是录播课视频播放简单作业用现成SaaS确实又快又省。但如果出现下面这几类情况SaaS往往撑不住一是销售模式特殊比如你有多级代理、合伙人分佣或者线下机构和线上课程需要打通SaaS的授权体系和订单字段很难改二是品牌和数据诉求强课程、学员数据都在别人平台上导出做精细化运营很费劲三是教学形式特殊比如必须做直播小班课、需要自定义学习路径SaaS只能给你能用的功能不能给你好用的业务逻辑。我还遇到过一类客户是先用SaaS跑了一阵然后想半定制——让SaaS厂商帮忙加几个字段。这类项目我通常劝他们谨慎底层数据模型不是你的开放API覆盖不了你全部业务厂商一升级版本你改的东西就全废了。与其在别人的地基上盖楼不如一开始就想清楚这个平台是不是你的核心资产。如果是定制开发这笔钱省不得如果不是用SaaS、把精力放在内容和招生上更划算。2. 需求调研先想清楚业务流程再谈界面设计定制开发项目里我最怕的需求文档是参考某某平台的样式做一个类似的。页面长相是最容易抄的真正难的是页面背后的流程。所以我的需求阶段有一个硬规矩先画业务链路再画界面草图最后才谈技术方案。顺序反了后面就是无穷无尽的需求变更。2.1 画业务链路图把每个节点的人、状态和异常都标出来我习惯和客户业务负责人坐在一张桌子前把一个学生从看到课程到学完课程的完整过程一个节点一个节点地过。以购课为例典型链路是学员看到课程 → 注册/登录 → 浏览详情页含试看→ 下单生成待支付订单 → 跳转第三方支付 → 支付回调 → 订单变成已支付 → 系统解锁课程 → 学员开始学习 → 播放器记录进度 → 学习完成 → 可评价 → 如有问题可申请退款 → 退款审核 → 退款成功 → 课程关闭画这条链路的重点不是主干而是每个节点上的人、状态、异常。比如支付这个节点异常就有好几种用户付了钱但回调没到、回调到了但金额对不上、用户重复点击下单、用户支付成功后马上退款。每一条异常都要在需求阶段定下处理规则否则到了开发阶段就是开发同学自己拍脑袋做出来的行为未必符合业务预期。学习链路也一样。一节视频课什么算学完是播放到结尾就算还是播放时长超过70%算可不可以拖进度条刷课时需不需要防挂机这些看起来很小的问题直接决定你进度计算、完课率统计、证书发放的逻辑。我见过一个项目上线两周后才发现学员把视频拖到结尾就算完成完课率虚高得让运营根本没法看数据。2.2 用必须做/可以后补/先不做砍出第一版需求阶段最难的不是梳理而是砍需求。我的做法是把模块地图里的每一项按三个桶分类必须做、可以后补、先不做。判断标准很简单——如果不做这件事核心业务能不能转起来。第一版我认为必须有的只有四块课程发布后台能上传章节视频、课程购买含支付和订单、课程学习视频播放加进度记录、用户管理学员账号和权限。这四块是一条完整的发布-售卖-学习闭环缺任何一块平台都跑不起来。可以后补的包括直播、作业考试、优惠券、积分、社区问答、证书、数据报表。这些功能不是不重要而是它们不决定能不能开班只影响体验好不好。先不做的是复杂的代理分销、多级分账、CRM对接、智能推荐这类重运营能力。这类功能往往要随着业务跑起来才清楚怎么做提前做就是闭门造车。我见过不少团队一上来就规划了十几个模块开发了半年还没上线。原因就是什么都想做结果每块都做不深。第一版把核心四条链路打磨到极致比一堆半成品模块有价值得多。2.3 角色权限一个权限表避免后面改到哭在线教育系统天然多角色学员、教师、运营、财务、管理员。权限如果不在需求阶段理清楚开发到一半再来改代价极高。我最常用的工具是一张角色权限矩阵表行是角色列是菜单和关键操作交叉格里填写可看、可操作、不可见。这张表里最容易出问题的不是功能权限而是数据权限。功能权限管的是能不能点这个按钮数据权限管的是能看到哪些数据。比如一个教师他应该只能看到自己课程下的学员和作业而不是全平台的学员列表。这个区分在需求文档里必须明确写出来。常见的漏洞是后台只校验了用户是否登录、是否教师角色但没校验这个学员是不是属于这个教师。结果就是教师调用接口时把学员ID一换就能查到别人的作业和手机号。这种问题在需求阶段画一张数据权限矩阵就能避免到测试阶段再发现往往已经涉及一批接口的改动。3. 架构取舍别为了微服务三个字过度设计我遇到过不止一个团队系统还没做先跟我谈要用微服务、要用容器原生、要做灰度发布。每次我都要泼一盆冷水在线教育平台的第一版大多数情况下单体架构加清晰的模块边界就是最优解。技术选型不是越新越好是越合适越好。3.1 单体架构 清晰模块边界才是教育平台的最优解真正做过微服务的人都知道微服务带来的复杂度是实打实的服务发现、配置中心、分布式链路追踪、跨服务事务、部署编排任何一项都要投入人力。在线教育平台起步阶段通常不超过万人同时在线单体架构完全扛得住但会带来一个隐患代码没有边界模块之间互相调用时间长了变成一坨。所以我的建议是模块化单体代码仓库还是一个但是内部严格划分模块比如用户模块、课程模块、订单模块、学习模块、视频模块。模块之间只能通过接口调用禁止跨模块直接修改对方的数据库表。这样做的好处是将来业务量上来了哪个模块是瓶颈就单独把哪个模块拆出去拆的成本比从一开始做微服务低得多。以订单和学习进度为例如果一开始就拆分成两个服务那支付成功之后解锁课程这个动作就涉及跨服务事务。你先要更新订单状态再要往学习中心插入一条用户课程关系两步必须同时成功或同时失败。一上分布式事务排查问题的难度翻倍而在模块化单体里就是一个数据库事务里两条SQL的事。3.2 我常用的技术栈与部署形态技术选型上没有绝对标准我的习惯是优先考虑团队熟悉度而不是追逐热门。毕竟一个团队用不熟的技术再先进也发挥不出效果。下面是我在多个在线课程系统项目里比较常用的一套组合层次选型理由前端Vue3或React生态小程序用跨端框架组件成熟、上手快、招聘容易后端Spring Boot或Node.js/NestJS生态稳定按团队背景二选一数据库MySQL Redis核心业务强事务缓存扛热数据搜索Elasticsearch课程搜索、分类筛选、标签聚合文件视频对象存储 转码服务 CDN不自建存储和分发成本可控部署Nginx Docker规模大了再上编排初期运维简单单机也能跑这里我特别说一下为什么数据库选MySQL而不是那些分布式数据库。在线教育的核心数据是订单、课程、学习记录这些数据的特点是强一致、事务性强MySQL在这类场景下非常成熟可靠。至于并发量和数据量大部分平台离单表撑不住还差得很远。真到了那一天先做读写分离、分库分表而不是一上来就上分布式数据库给自己找罪受。Redis在这套体系里承担的事很多缓存课程详情、存登录态、给订单号做幂等去重、给库存做原子扣减、存热点数据。可以说没有Redis这个系统的高并发能力会差一个量级。但也要记住Redis是缓存不是数据库关键数据一定要落库缓存只用来加速。3.3 数据库设计课程商品与学习记录的两处关键建模在线教育系统的数据库设计有两个地方最容易错我每次都要单独强调。第一个是课程的商品模型。很多团队建一张课程表把价格、有效期、库存直接挂在课程上。这看起来简单但业务一复杂就出问题同一个课程开三期班三期班价格不同、有效期不同、教材版本不同你怎么办正确做法是拆成两层课程SPU是商品展示层包含标题、封面、简介、详情课程计划SKU是具体可售卖的班期包含价格、原价、有效期、开课时间、库存、状态。学员购买的是某个课程计划学习进度挂在课程计划之下。这样一套模型才能支撑同一个课卖多期、做促销、做组合售卖后面加优惠券和会员体系也不会推倒重来。第二个是学习记录表。我看到不少团队的学习记录字段就一个进度百分比。但学员看视频时拖进度、断点续播、反复看同一节这些操作如果只存一个百分比根本不够用。我的做法是学习记录表以(user_id, section_id)为唯一键记录最近观看位置、累计观看时长、完成状态、最后更新时间。前端播放器每10到15秒上报一次拿到服务端就更新这张表。课程总进度由后台实时计算用已完成的章节数除以总章节数得出。这里还要考虑防刷。如果完成条件只依赖看完就上报完成率就算100%用户拖进度条就能刷完。所以我在播放器侧做了两层校验一方面要求播放位置达到整节视频时长的90%以上才允许标记完成另一方面服务端记录有效观看时长如果一节课时长60分钟观看日志累计不到5分钟就标记完成直接判为异常。这块逻辑不写清楚后面数据报表全是泡沫。4. 核心业务链路课程、学习、订单的实现细节架构定了以后真正的硬骨头是核心业务链路的实现。我常跟团队说这个系统百分之八十的业务逻辑都藏在课程、学习、订单三条链路里。每一个环节都有大量细节这里挑几个最容易翻车的点展开。4.1 从课程SPU到学习章节的数据模型数据模型和业务流程是要对着看的。我在需求阶段画的学员从看到课程到学完课程链路图落到数据库就是课程、章节、小节、学习记录这几张表的关系课程表保存商品信息课程计划表保存可售卖班期每个课程计划下挂一到多个章节章节下挂多个小节小节可以是视频、课件、直播回放统一用类型字段区分。小节上还有一个关键字段是否试看。试看逻辑在在线教育里是标配——免费用户只能看标记为试看的小节付费学员才能看全部。为什么要把试看设计在小节而不是课程上因为可以灵活控制有些课开放前两节试看有些课开放一节试看加一段宣传片运营在后台直接改小节属性就能调整引流策略不需要开发介入。还有一个容易忽略的设计课程计划与章节的关系。直播班期结束后直播回放会成为这个班期的固定内容这里我用的是直播小节转回放机制——直播结束后异步生成回放视频更新小节数据。这样学员的观看页面不用变后端只是把视频源从直播流换成了回放地址对学员无感知。4.2 学习进度与作业考试的状态流转学习进度这块我在前面建模里讲了表的字段这里说下状态流转的实际体验播放器每15秒上报一次观看位置后端只做一件事——更新学习记录表的最后位置和累计时长。当上报的位置超过整节视频时长的90%时再把完成状态置为完成。这个90%是我在很多项目里反复验证后定的值超过了不容易被看到结尾才算完的严格逻辑卡住又不会因为看了开头就误判。作业和考试这类教学互动功能核心是状态机设计。作业的状态不能只用一个是否已提交的布尔值因为实际业务里有退回重交、超时补交、批改后申诉这些流程。我常用的一组状态是未提交 → 已提交 → 批改中 → 已批改 → 已退回 → 重新提交 → 已批改每一跳都要做校验。比如已批改只能由教师触发已退回必须带批改意见重新提交之后上一份答案要保留历史版本。这里我最常提醒开发同学的是防重复提交学员手抖点两次提交服务端要保证只生成一条作业记录方法是前端提交按钮置灰加后端按(user_id, homework_id)唯一约束兜底。考试模块比作业更重因为它有关闭时间和自动判分。自动判分只适合客观题主观题必须走人工批改。为了避免学员互相传答案我会把客观题的选项顺序随机打乱同一道题不同学员看到的选项排列不同提交后按题号对应到原始选项判分。这个细节虽然简单但在防作弊上很有效。4.3 订单支付的幂等设计与对账机制订单支付是整个系统里最不能出错的地方直接关系钱。支付的核心难点不在调起支付而在回调处理和异常补偿。我先把完整的支付流程列出来学员提交订单 → 后端创建订单状态为待支付→ 后端请求第三方支付平台获取支付参数 → 学员完成支付 → 支付平台回调后端 → 后端校验签名和金额 → 幂等处理 → 订单状态改为已支付 → 给学员开通课程 → 发送通知这里面任何一个环节失败都不能让用户付了钱而没开课或者没付钱却开了课。幂等处理是回调逻辑的核心。支付平台在极端情况下会重复回调或者学员付完款后网络断了又重试所以回调处理一定要支持重复执行且结果一致。一段简化后的幂等逻辑大概是这样的// 伪代码订单支付回调幂等处理 public void handlePayCallback(payOrderNo, payAmount, signature) { // 1. 校验签名防伪造回调 if (!verifySignature(payOrderNo, payAmount, signature)) { throw new SecurityException(回调签名校验失败); } // 2. 用订单号加分布式锁保证并发下只有一个线程处理 boolean locked redisLock.tryLock(PAY_CALLBACK_ payOrderNo, 10); if (!locked) { return; // 另一个请求正在处理直接返回 } // 3. 查订单如果已经是已支付状态直接返回成功幂等 Order order orderMapper.selectByOrderNo(payOrderNo); if (order.getStatus() PAYED) { return; } // 4. 校验金额与订单金额一致 if (!order.getAmount().equals(payAmount)) { throw new BizException(金额不一致需人工介入); } // 5. 同一个数据库事务里更新订单、插入用户课程关系 transaction(() - { orderMapper.updateStatus(payOrderNo, PAYED); userCourseMapper.insert(userId, planId, expireTime); }); }这版逻辑里有一个容易被忽略的点给用户开课和更新订单必须在一个事务里。如果先更新订单再开课开课失败就会导致用户付了钱但看不了课如果先开课再更新订单回调重试时又会重复开课。一个事务解决两个问题。回调之外还必须有主动对账。现实里偶尔会有用户支付成功但回调丢失的情况所以我会加一个定时任务每10到15分钟扫描一次超过30分钟仍未支付的订单主动向支付平台查询真实状态如果发现已经支付了就走和回调一样的开课逻辑。另外每天凌晨还要做一次全量对账把本地订单表和支付平台下载的账单逐笔比对金额不一致的标记出来人工处理。5. 视频体系在线教育系统的命门在线教育平台最核心的资产就是内容内容的载体绝大多数是视频。我可以直接说视频处理这条链路没做好平台其他功能再完善也白搭。这一节我详细讲视频从上传到播放的全过程以及每个环节的实际取舍。5.1 上传、转码、存储与分发的流水线老师上传一个原始视频通常默认是1080P甚至4K的大文件几个GB很常见。这个文件不能直接拿来给学员播放原因有两个一是太大学员手机流量吃不消二是格式兼容性问题原始编码未必能在所有浏览器和手机上播放。所以要有一台转码流水线标准流程是上传到私有存储空间支持分片断点续传→ 提交转码任务 → 转码服务输出多分辨率版本 → 生成封面图和预览动图 → 将转码产物发布到CDN → 播放器按清晰度拉流。转码输出的清晰度档位我一般建议至少三档360P给弱网用户720P作为默认画质1080P给带宽好的用户。码率设置上以常见的网课画面PPT加老师头像为例720P建议控制在1.5到2Mbps之间1080P在3到4Mbps之间。码率不是越高越好码率过高导致播放卡顿学员体验反而更差屏幕录制类的课程画面变化小用更低的码率就能达到清晰度。封装格式我建议统一用HLS。它的核心优势是切片和自适应视频被切成一个个小分片播放器可以根据实时网速自动切换清晰度弱网时降到360P网络恢复再升回720P整个过程不打断观看。这也决定了播放器选型的方向——不支持HLS的播放器在后面那一步会很被动。5.2 播放器的坑与防盗链方案播放器的选型第一版完全可以用浏览器原生video标签加一套HLS播放库搞定前提是把下面几个坑处理好。第一个坑是iOS上的自动播放限制。Safari默认不允许带声音的视频自动播放需要设置playsinline并且静音时才能自动播放。如果不处理学员点进课程页视频黑屏不播放90%是这个问题。第二个坑是Android机型碎片化。部分老设备的内置浏览器对HLS支持不佳要用HLS播放库做兼容或者强制走检测失败降级到MP4播放的方案。第三个坑是播放器实例的内存泄漏。很多页面跳转后不销毁播放器视频还在后台解码连续看几个视频就卡死或黑屏必须在路由切换时调用销毁方法。再看防盗链。视频地址如果不做任何保护被别人抓走挂在其他网站上是迟早的事。我在项目里用的方案是CDN签名URL加时限校验播放器每次请求视频地址服务端动态生成一个带签名和过期时间的URL过期时间一般设10到30分钟。学员请求一次拿到地址到期后重新申请这样直接拿走链接的人过一会儿就打不开了。这里要泼一盆冷水没有任何方案能完全防住录屏。我见过做得很重的给视频做全链路加密、播放器做防录屏检测结果技术上绕来绕去对盗版行为的遏制效果有限还拖累了播放体验。对绝大多数在线教育平台来说最务实的方案是签名URL防盗链、播放时右下角显示学员ID水印、播放器禁右键禁离线缓存。学员ID水印特别值得做一旦有人录屏传播运营能根据水印直接定位到人这比任何加密技术都有效。5.3 直播模块自研还是接第三方服务说完录播再聊直播。在线教育里直播有两种形态一种是老师对大量学员的单向大班直播几百上千人同时看另一种是老师与学员互动的小班课几十个人以内要开麦开视频。我的建议很清楚大多数团队不必自研直播接第三方服务更划算。原因很简单直播涉及流媒体协议、大规模并发分发、弱网优化、区域调度每一块都是专业性很强的领域自研的人力成本和时间成本远超一般人想象。以大班直播为例第三方服务商负责推流、转码、分发你的后端要做的是创建直播间、生成推拉流地址、管理上麦权限、人员进出记录、直播结束生成回放。这些业务逻辑就足够你写一阵子了没必要碰底层音视频。如果确实要自研我只建议做小班互动这一种场景。技术路线上互动实时性用WebRTC延迟低到能正常对话同时给旁听学员用低延迟直播流。实践里这个组合已经比较成熟。但前提是团队里有懂音视频的人否则我依然会劝你接入第三方。直播结束后的回放生成要提前设计好直播流录制后异步转成录播视频自动挂到课程计划下这样直播课结束当天就能变成可回看的录播课对学员来说错过直播还能补课很重要。6. 从实战项目里捡出来的几个坑做了这么多年定制开发很多坑都是踩过之后才总结出来的。这里说的不是技术细节而是那种如果没人提醒你大概率也会栽一次的项目级坑。我把印象最深的几个写出来。6.1 视频成本被严重低估几乎每一个第一次做在线教育的客户都会低估视频的存储和带宽成本。我算过一笔账如果一个平台有1000节课每节按2个GB原始文件算光原始视频就是2TB存储转码后还有多分辨率副本又翻一倍。这还只是存储。学员观看时走的CDN流量才是大头——一节720P的课一小时大概产生600MB到1GB流量一千个学员完整看完就是将近1TB的流量。这些成本按月累积是个相当可观的数字。怎么控成本我的经验是四招第一原始文件转码后移到冷存储或者按保留周期删除没必要所有原始文件都留在热存储里第二合理设置码率档位不无脑上高清第三CDN开启缓存和压缩利用浏览器缓存减少重复流量第四对以音频为主的课件提供纯听模式让学员可以关闭画面只听声音音频一小时才几MB成本只有视频的零头。我记得有个客户运营同学为了体现课程质感把所有课程都按1080P高码率转码上线一个月云厂商账单比预估高了三倍。后来我们做了两件事把历史课程统一转成720P为主、1080P按需的档位再给课程详情页加了清晰度记忆功能第二次播放自动选上次的清晰度。一个月后流量成本降了四成学员反馈反而更好了因为卡顿少了。6.2 活动高峰期的并发处理在线教育平台的流量峰值非常集中早上10点、晚上8点、周末、开学季、大促开抢都是压力激增的时间点。很多系统平时跑得好好的一到活动就崩根子在于没想清楚峰值靠什么扛。这里有个基本分层一切静态资源图片、视频、压缩包课件必须走CDN绝不能放在应用服务器上由业务接口读出来返给前端。我处理过一个案例某机构做9块9引流课宣传海报一发出几万人同时涌进页面而他们的课程封面图全放在应用服务器上带宽瞬间被打满连登录接口都响应不了。后来把所有图片迁到对象存储加CDN应用服务器只处理动态接口问题立刻消失。动态接口的扛压设计也有固定套路课程详情页是访问最密集的接口直接查数据库绝对扛不住必须把详情缓存到Redis为了防止缓存同时过期导致击穿我一般设计成永不过期加异步刷新——后台任务定期把新数据写进缓存前台只读缓存逻辑上规避了雪崩问题。再就是下单接口秒杀场景下不能让所有请求都直接打到数据库要前置一层Redis原子扣减库存扣减成功的才进入后续下单流程数据库那一下只承受很小的写压力。还有一个人人都知道但经常做不好的点短信验证码接口必须限流。活动期间用户疯狂点击获取验证码如果不限流短信费用和接口压力都扛不住。我一般会做同一手机号60秒内只能发一次、单IP每小时最多发10次这种基础策略再配合图形验证码兜底。6.3 安全与合规内容审核和数据隐私在线教育平台有两类安全问题是必须认真对待的一类是内容安全一类是数据隐私。内容安全指的是平台上所有用户可产生的内容教师上传的课程、学员提交的作业、论坛里发的帖子都需要审核。教师上传的课程如果不审核就上架出了违规内容平台是要担责任的。技术上我的方案是机器审核加人工抽检文本内容过关键词过滤和内容安全检测接口图片和视频先机器识别机器认为有问题或拿不准的转人工。审核状态要嵌进课程的整个生命周期里课程草稿 → 提交审核 → 审核通过 → 上架这个状态字段从第一版就要设计好不能等出事了再补。数据隐私方面在线教育系统收集了大量个人信息手机号、姓名、学习记录、支付信息。我的底线是三条个人信息加密存储普通管理员在后台看到手机号要脱敏显示所有涉及个人信息查询的接口要做权限和数据范围校验防止越权日志系统里不能打印完整手机号和支付信息。不要觉得这是大平台才需要考虑的事小平台出事更伤一个信息泄露事件足以让家长对机构的信任清零。数据安全这件事应该从架构设计的第一天就做进去而不是上线后补救。7. 上线不是终点测试、监控与第一周运营节奏系统开发完了、功能都跑通了这只是上半场。我见过太多项目在上线这个节点松懈结果上线第一周被各种问题打懵。真正的考验从上线那一刻才开始这里说下我自己的项目上线流程。7.1 多端兼容测试怎么安排在线教育系统的终端极其分散iOS的Safari和App内浏览器、Android的各种机型自带浏览器、小程序、PC端。每个终端的环境不一样支付、播放、登录这三个场景最容易出兼容性问题。我通常在提测阶段就拉一张兼容性测试矩阵把重点场景逐项列出来终端重点测试场景iOS Safari / App内WebView自动播放、断点续播、支付回调返回Android微信内置浏览器 / 自带浏览器HLS播放、返回键逻辑、页面重载小程序端登录态同步、虚拟支付限制、后台播放PC浏览器管理后台、键盘快捷键、多窗口播放网络环境测试比终端测试更容易被忽略但实际体验影响最大。要专门用弱网工具模拟2G/3G网络验证播放器在低带宽下的表现视频能不能自动降到低清晰度、拖进度条要等多久、断网重连后能不能恢复播放位置。这块不做学员在地铁里打开课程就黑屏转圈投诉率会直线上升。支付功能建议在沙箱环境跑全流程再用真钱小额交易做最后的回归验证。我一般让测试同学用0.01元真实支付分别走支付成功、支付后取消、支付后立刻退款这三条路径百发百中不踩坑。7.2 技术指标与业务指标双监控上线后的监控我习惯分成技术指标和业务指标两条线缺一条都容易出问题。技术指标看的是系统健康度接口QPS、P95响应时间、错误率、CDN命中率、视频起播耗时、播放卡顿率、支付回调延迟、短信发送成功率。这些指标要有告警阈值比如支付成功率低于95%要立刻告警、播放卡顿率超过5%要查是否CDN配置出了问题。视频类指标尤其要盯因为视频问题用户感知最明显而且一旦出现问题往往是大面积同时爆发。业务指标看的是平台有没有在正常运转注册转化率、下单转化率、支付成功率、试看转购率、完课率、退款率、次日留存。这些指标直接反映运营动作的效果。比如一次活动带来大量注册但完课率很低说明课程内容或新手引导有问题退款率突然升高往往和课程质量或承诺不符有关要联动运营检查。技术指标告诉你系统没崩业务指标告诉你业务没死两个都看才完整。7.3 上线第一周每天要做的三件事新系统上线后的一周是问题集中暴露的窗口期。我的习惯是上线第一周每天固定做三件事顺序不能乱。第一件查支付对账。每天上午第一件事把前一天的第三方支付账单和本地订单做一次人工抽检看看有没有支付成功但未开课退款未到账这类极端情况。支付问题不能等用户投诉一定要主动发现晚处理一小时就可能多一个投诉工单。第二件看播放链路的核心指标。重点盯这几项CDN命中率、播放器起播失败率、各清晰度播放占比、卡顿率。如果起播失败率突然上升优先怀疑视频地址签名逻辑或CDN配置如果卡顿率上升看是不是码率档位设置不合理。学员对平台的耐心往往集中在前三次观看体验里播放问题不处理完课率会断崖式下跌。第三件收集业务方的真实反馈。让运营和老师把每天遇到的问题记录下来晚上汇总一轮按优先级分好类。第一周的重点不是提优化需求而是把崩溃、无法支付、无法播放这类阻断性问题清零。等稳定跑过一两周再开始讨论体验优化和新功能排期。最后分享一个我个人的体会。做在线课程系统定制开发这么多年我越来越觉得衡量一个教育平台好坏的标准不是功能列表有多长而是发布课程-购课-学习这条主链路做得有多扎实。很多团队把精力花在加各种花哨功能上最后核心链路反而一堆边角问题。如果你正要开始做这样一个系统我给你的建议是把支付回调的幂等逻辑和视频播放的异常处理当作头等大事来设计这两个地方稳了平台就稳了一大半这两个地方出问题用户流失的速度会快到你来不及反应。