企业官网建设流程全解析

在线教育系统这些年属实被市场反复教育过一轮又一轮，从早期录播课平台到后来直播大班课、小班课、一对一，再到企业内训、知识付费、职业技能培训，每个赛道对系统的要求都不一样。我前后带团队做过几套在线课程系统的定制开发，也接手过不少“先买SaaS用着，后来发现不好使”的烂摊子，今天把核心的东西拿出来聊一聊。这篇文章不聊虚的，就聚焦在线教育系统定制开发的底层逻辑、技术选型、业务模块拆解、性能瓶颈和常见坑，适合准备自建系统的技术负责人、创业团队，以及想搞清楚“定制开发到底定的是什么”的甲方朋友。

1. 内容整体设计与思路拆解：定制开发到底在“定”什么

1.1 为什么不能直接套用现成SaaS方案

很多团队一开始的想法是“先买个现成的网校系统，便宜又省事”。这个思路在业务验证期没问题，但凡做到一定规模，痛点会非常具体。我接触过一个做职业资格培训的客户，买了某SaaS网校后遇到三件事：第一，学员报名某门课程后，系统不支持按章节拆分为多个老师分别结算；第二，他们的业务里有大量线下班转线上同步课的场景，SaaS只支持纯录播；第三，用户积分体系想跟自有CRM打通，SaaS厂商直接回复“接口不开放”。

这三个问题单看都不大，但叠加起来，就是业务被系统卡住了。定制开发的核心不是为了“显得高级”，而是围绕业务流程做适配。你得先想清楚：你的商业模式、课程交付方式、学员生命周期管理、师资结算逻辑、营销玩法，哪些是行业通用的，哪些是你独有的竞争力。通用部分可以借鉴成熟方案，独有部分才是定制开发的发力点。

我一直跟客户强调一个原则：定制开发不是把能想到的功能全做一遍，而是做“业务关键路径上的专属能力”。比如你做的是少儿编程培训，那课程系统里必须有作业提交、代码运行环境集成、学习报告自动生成；你做的是成人考证培训，那题库系统、模考系统、错题本、学习计划就是命根子。功能堆砌是最容易的，难的是每个模块怎么贴合你的教学法。

1.2 定制开发的三个常见层次

根据我这些年跟各类甲方打交道的经验，定制开发通常分三个层次，很多团队没搞清楚自己要哪一层，导致预算和工期估算严重失真。

第一层是界面与品牌定制。换LOGO、换配色、调整页面布局、配置首页模块。这个层次本质上是SaaS的深度配置，技术含量不高，但确实能满足一部分“看起来不像用模板”的需求。

第二层是业务流程定制。比如上面提到的多老师分账、线下班与线上课联动、学员转班退班规则、自定义审批流、排课系统与线下教室资源绑定。这个层次开始涉及数据模型设计、状态机设计和权限体系设计，需要真正理解业务。

第三层是技术能力定制。包括直播方案选型、音视频处理管线、高并发选课抢课、数据中台打通、个性化推荐算法、AI助教等。这个层次比拼的是技术深度，也是市面上大多数“定制开发”项目最终翻车的地方——团队只做了第二层的功能，却按第三层的标准收费，或者反过来，用第三层的技术方案去解决第二层的问题，成本完全失控。

1.3 项目启动前必须想清楚的四件事

在进入技术细节之前，我把项目评估阶段最关键的四件事列在前面，这些是决定项目成败的“前置条件”。

第一，明确核心使用对象。系统是给谁用的？学员端、教师端、教务管理端、机构管理端、家长端（K12场景）还是渠道分销端？不同角色的使用频率和操作复杂度差异很大，直接决定前端技术栈和移动端策略。我见过最离谱的需求是甲方要求做一个App，结果80%的用户都是在微信里点链接学习，根本不会下载App。

第二，想清楚课程交付形态。录播、直播大班课、直播小班课、一对一互动课、AI课、线下双师课，这几种形态的技术复杂度是递增的。如果一开始就规划了直播互动课，那WebRTC、IM、白板、音视频网关这些组件就必须在架构设计时预留好位置，后面再加会非常痛苦。

第三，预估真实的并发规模。在线教育系统的并发跟电商不一样，它是典型的“脉冲式并发”。比如某考证机构在报名季放出来1000个名额，10分钟内被抢完；或者某场名师直播课开始前5分钟，2万人同时涌入直播间。系统设计必须为这种“瞬间洪峰”做好准备，而不是按平均在线人数设计。

第四，确认数据与支付合规要求。这项极其关键，但常常被创业团队忽略。在线教育涉及未成年人信息（K12场景）、支付交易数据、课程内容版权，每一类都有对应的合规要求。支付必须走正规渠道、资金流向要清晰；用户敏感信息需要加密存储和分级授权；课程内容要有防下载防录屏机制；发票、退费流程要跟财务系统打通。

1.4 定制开发相对SaaS的真正优势

最后总结一下定制开发相对SaaS方案的核心优势。一是数据完全自有，学员数据、学习行为数据、交易数据都沉淀在自己的数据库里，这是做精细化运营和二次增值的前提。二是流程完全可控，你不需要迁就SaaS厂商的通用流程，业务变了系统可以跟着变。三是系统可演进，从单机到集群、从单体到微服务、从自建机房到云原生，技术升级的路径完全掌握在自己手里。四是接口彻底开放，跟CRM、ERP、企微、钉钉、公众号、小程序等外部系统的对接没有阻碍。

当然，劣势也明显：开发周期长、初始投入高、需要养技术团队或在项目期找靠谱的外包团队。所以我的建议是：业务逻辑还没跑通、模式还没验证的时候，先用SaaS或最小化产品跑起来；等业务模型清晰、数据资产开始积累、流程复杂度超出SaaS承载力之后，再启动定制开发。

2. 在线教育系统的核心技术架构选型

2.1 整体架构的经典分层

在线教育系统的技术架构，经过这些年的演进，已经有一套比较成熟的范式。简单画个分层，方便后面展开：客户端层（PC Web、H5、小程序、App）、接入层（API网关、CDN、负载均衡）、业务服务层（用户、课程、订单、学习、互动、营销等）、基础设施层（数据库、缓存、消息队列、对象存储、音视频服务）。

很多技术负责人上来就聊微服务、容器化、Kubernetes，我觉得这是把次序搞反了。对大多数在线教育系统来说，业务复杂度还没到必须拆微服务的程度，单体应用加良好模块化设计，配合水平扩展，完全可以支撑十万级甚至百万级用户。我建议的原则是“从简起步，按需演进”：先做模块清晰的单体应用，当某个模块确实出现独立的性能瓶颈或团队组织需要独立交付时，再拆成微服务不迟。

客户端层的选型有两条主流路线。一条是纯H5/小程序路线，优点是开发成本低、上线快、无需应用商店审核，缺点是直播互动体验和离线下缓存能力受限。另一条是原生App或跨端框架（Flutter/React Native）路线，体验更好但成本更高。我的经验是：录播为主、直播为辅的阶段，H5加小程序就够了；如果核心业务是互动直播课或者需要录制回放、离线下载，那就必须有App。很多成熟的在线教育公司会做“H5拉新、App沉淀付费用户、小程序裂变”的组合打法。

2.2 后端服务的核心技术栈

后端技术栈选择，我推荐建立在Java（Spring Boot/Spring Cloud）或Go这两种语言基础上。不是说出不了别的选择，而是这两个生态里，在线教育相关的开源组件、支付SDK、消息推送、IM集成方案最成熟，遇到问题能搜到的案例也最多。

Java适合业务逻辑复杂、需要大量CRUD和事务管理的系统，Spring生态的成熟度无可匹敌。Go适合高并发IO密集场景，比如直播聊天室网关、消息推送服务，协程模型写起来非常舒服。我做过一个项目是Java为主单体应用，同时用Go写了一个独立的IM网关服务，两个服务通过消息队列解耦，效果很好。

数据库选型方面，业务主库用MySQL（8.0+），缓存用Redis，搜索用Elasticsearch，文件与音视频用对象存储（阿里云OSS/腾讯云COS/MinIO自建），消息队列用RocketMQ或RabbitMQ。这套组合在在线教育领域非常成熟，不需要冒险用新型数据库。

有一个细节值得单独拿出来说：在线教育系统的数据模型里，课程内容往往有版本迭代。同一个课程，老师会不断优化视频、更换课件、调整章节顺序。如果课程内容直接关联到订单和学员的学习记录，版本一变就乱套。所以设计上要把“课程”和“课程版本”拆开，订单和学习记录都要锁定具体的版本ID，这样避免后续内容更新引发历史数据错误。

2.3 直播与音视频技术选型

直播是在线教育系统里技术壁垒最高的部分，也是定制开发和SaaS拉开差距的重要战场。市面上的方案大致分为三类。

第一类是第三方直播SDK集成（即构、声网、腾讯云、阿里云等）。适合大多数创业团队，把音视频传输、弱网优化、回声消除这些脏活累活交给专业厂商。需要注意的是：用第三方SDK不等于不用做架构设计，你仍然需要设计直播间状态管理、上麦流程、连麦权限、混流录制、聊天室与直播画面的同步逻辑。

第二类是基于开源方案自研。主流方案是WebRTC加选择性转发服务器（SFU），配合开源媒体服务器（如SRS、livekit、mediasoup）自己搭。这条路适合有音视频技术积累的团队，成本长期看更低，但初期坑非常多：NAT穿透失败、丢包恢复、码率自适应、多路流混流、录制存证……每一件都是硬骨头。我不建议没有音视频底子的团队直接裸奔自研，最好先找有经验的专家带队。

第三类是超低延迟直播与普通直播混合。一个容易被忽视的经验是：不是所有场景都需要“超低延迟”。纯授课型直播（学生只看老师讲、不连麦），用普通CDN直播（延迟3-5秒）就够了，成本远低于WebRTC。需要连麦互动的课，才用WebRTC的低延迟通道。我在实际项目中经常设计成双通道：默认走CDN直播，互动环节动态切到WebRTC，这样成本与体验能取得不错的平衡。

2.4 数据存储与图片音视频处理管线

在线教育系统的存储需求，跟普通Web系统差异很大，主要因为课程内容是非结构化数据且文件体积大。

对象存储是基础，但必须配合CDN使用。视频文件直接给用户播放地址会导致源站压力大、跨地域访问慢、高并发时被流量打垮。正确做法是：对象存储做源站，CDN做分发缓存，用户端播放器直连CDN边缘节点。这里有个经验值：视频文件建议至少缓存到CDN节点7天以上，不然热播课程会频繁回源，产生大量源站流量费用，播放体验也会卡顿。

音视频处理管线也要提前设计。老师上传录制好的课程视频后，需要经过转码（适配不同分辨率、码率）、切片（HLS格式）、封面截取、水印叠加、内容审核等工序，最终生成多码率的播放列表。视频上传后，通常要几十秒到几分钟才能上架，这中间其实是异步任务在干活。我建议用消息队列加任务队列的方式做：用户上传完成后立刻返回“处理中”状态，后台管线转码完成后通过回调更新课程状态，同时推送通知给运营人员。

如果用第三方云厂商的媒体处理服务，方式类似，但要注意回调与重试机制的设计。媒体处理服务回调你的接口时，你的接口必须幂等，而且处理成功与否要有明确的ACK机制，否则回调丢了会导致视频永远卡在“处理中”。

3. 核心业务模块设计与实操要点

3.1 用户体系与权限控制

用户体系是整套系统的地基。在线教育系统的用户角色至少有：学员、讲师、助教、教务管理员、财务、超级管理员、渠道代理，K12场景还有家长。这些角色的数据模型如果不在一开始设计好，后面每一次权限调整都够喝一壶的。

我建议用RBAC（基于角色的访问控制）+数据范围权限的组合。RBAC管的是“谁能做什么操作”，数据范围管的是“操作哪个范围内的数据”。比如：讲师只能看自己名下课程的数据，区域代理只能看自己渠道带的学员数据，财务只能看跟订单和结算相关的数据。别怕麻烦，在线教育经常出问题的不是功能不好用，而是权限太粗导致数据泄露。

登录认证建议直接用JWT加Redis存储会话的方案，简单可靠。用户密码必须用bcrypt加盐哈希，绝对不能用MD5。短信登录、微信授权登录、Apple登录（如果有iOS端必须做）这些第三方认证渠道，建议通过统一认证抽象层处理，后续加新渠道不用改业务代码。

有一个实操细节：在线教育用户存在“一人多角色”的情况。同一个手机号，既可以是某机构的学员，也可以是另一个机构的讲师。所以在设计用户表时，要把“用户基础信息”和“用户在某个组织/机构下的角色信息”分开存，避免把两种身份强耦合在一张表里。

3.2 课程与内容管理模块

课程管理是整个教学业务的核心载体。一个相对完整的课程数据模型至少要包含：课程（Course）、课程版本、章节（Chapter）、课时/内容单元（Lesson）、课件附件（PPT/PDF/Word）、视频资源（关联转码产物）、作业/测验（可选的单元）、资料下载区。

这里有个要点：很多团队把“课程”当成简单的一张表，结果做营销活动时才发现需要给课程加标签、加推荐权重、加捆绑销售关系，改起来很痛苦。我建议在一开始就给课程预留扩展字段，同时设计好“课程分类”“课程标签”“课程与讲师的关系”“课程与机构的关系”这几个常规维度。分类采用无限级树结构，方便后端运营灵活调整。

课时单元是学员真正“消费”的内容，学习进度必须精确到课时。学员观看视频时后端要定时上报进度，每5-10秒上报一次即可，没必要做秒级实时存储。课程学完状态的判定，不能只看视频播完，还包含课件阅读、作业提交、测验通过等情况，这块要跟业务方确认清楚“学完”的判定规则。

内容安全方面，视频播放建议强制使用加密HLS，配合自定义播放器鉴权。所谓加密HLS，就是对视频切片做AES-128加密，播放器从你的后端获取密钥后再解密播放。这个方案能拦住90%的“复制链接到处传”的低级盗版行为，但拦不住用录屏软件翻录。对付录屏，业界至今没有完美方案，只能在播放器层面做防录屏检测、暗水印（在画面周期性叠加用户ID）、明水印等威慑手段。

3.3 订单、支付与退款

在线教育交易有个特点：虚拟商品的交付与售后政策高度依赖内容形态。录播课的退款政策跟直播课不一样，训练营的退款政策跟单次购买又不一样。支付模块要设计成可配置的退款策略驱动，而不是写死逻辑。

支付渠道上，国内主流的方案是微信支付和支付宝。设计时统一走“业务订单号 + 渠道支付单号”的双轨制：业务系统生成自己的订单号（全局唯一），支付渠道有自己返回的流水号，两套号段都要存库，后续对账全靠这个映射关系。

做支付接入时，有几件事必须刻在脑子里。

第一，支付回调必须做幂等处理。支付渠道的通知可能会因为网络抖动重复推送，你的回调接口要根据业务订单号做状态判断，只有待支付状态的订单才能更新为已支付，否则丢弃并返回成功。同时，你处理完业务逻辑后必须给支付平台返回正确的应答，不然平台会以为通知失败继续重试。

第二，必须做每日对账。每天凌晨拉取支付平台的账单文件，跟本地订单表逐笔核对。这一步能发现单边账（用户扣款了但你这边订单还是待支付）、金额不一致、退款状态不一致等问题。很多团队不做对账，月底财务对不上账才着急，那都是没挨过打。

第三，退款要走原路退回。线上支付的订单退款必须原路退回，且退款事务与订单状态更新要放入同一个本地事务，避免退款成功但订单还是已支付状态。

课程订单经常涉及一个特殊场景：优惠券、满减、积分抵扣、渠道分成同时存在。这种多级优惠的计算逻辑建议用“价格计算器”模式，把每个优惠项实现为一个可叠加的计算节点，而不是在业务代码里写一长串if-else。每个计算节点都记录优惠金额和优惠前后快照，方便问题排查和财务审计。

3.4 学习过程跟踪与教学互动

学习过程跟踪是在线教育区别于传统电商系统的核心模块。学员看了哪些课、每节课看了多久、做了哪些作业、正确率多少、在哪个知识点停留时间最长，这些是优化教学内容和做个性化推荐的基础数据。学习行为数据的特点是“写入频繁、读取模式固定”，所以建议采用“行为日志实时写入 + 定时汇聚”的两层结构：实时层用消息队列接收行为事件，经过清洗后写入ClickHouse类的分析库，业务展示时查分析库的汇总结果，没必要把明细数据直接暴露给业务查询。

教学互动模块根据不同课程形态差异很大。录播课的互动主要是问答区和笔记；直播课的互动是聊天室、连麦、白板、抢答器、计时器；AI课则是轻互动的选择题、拖拽题和语音评测。互动模块选型时，IM服务是重点。自研IM成本不低，建议初期直接用腾讯云IM或融云，标准功能够用。如果你对数据敏感或者需要深度定制消息类型（比如白板操作消息），那IM网关自研或其他具备上下行消息定义能力的服务，也可以纳入考量。

白板是直播课里被低估的一个高频组件。简单说，白板的本质是一块所有端同步状态的画布，核心要求是“低延迟、可回放”。低延迟靠WebSocket/WEBRTC数据通道做增量同步，可回放意味着白板操作要落库存档。这个组件定制开发的难度中等，但坑很多：不同端画板坐标缩放、橡皮擦的透明度处理、图片与文字在画布上的拖动、断线重连后的状态补偿。如果你不是特别需要深度定制，优先考虑第三方白板SDK。

3.5 营销与分销系统

在线教育获客成本居高不下，营销系统的重要性不亚于教学系统。常见的营销玩法包括：拼团、秒杀、优惠券、砍价、分享得课时、老带新返佣、渠道代理分销。这些玩法的核心逻辑都围绕拉新、转化、裂变、留存四个环节展开。

我做营销系统的建议是：先把用户增长和用户关系模型设计好。比如拼团玩法，需要记录团长是谁、参团成员有哪些、成团状态、每个人对应的订单；分销玩法需要记录推广关系链（谁发展谁）、佣金比例、提现规则。这些关系数据是一张巨大的有向图，设计表结构时要注意查询效率，避免高频场景出现深链路的递归查询。

有一个必须提醒的点：营销规则的防刷设计。在线教育行业的黑产盯上营销活动是常态。比如拼团活动，黑产会批量注册小号参团套取奖励；秒杀活动会被脚本抢购。防护手段包括：注册环节的滑块验证、设备指纹识别、同一设备限制绑定账号数、活动规则的频控和异常检测。别嫌麻烦，等你的活动被薅一次羊毛，损失往往足够把整年的技术预算都搭进去。

分销佣金结算的规则设计也要仔细。成长值、课时包、阶梯分成、提现最低门槛、结算周期，这些参数化配置必不可少。尤其是结算状态机，要覆盖“预估可结算 → 已达成待结算 → 已结算 → 已提现/已失效”的全链路，避免财务在月底对账时才发现各种边缘case。

4. 常见性能瓶颈与高并发应对实录

4.1 选课抢课场景的“脉冲式洪峰”

我在前面提过，在线教育系统的并发是脉冲式的。最典型的场景是选课季：某门名师课放出500个名额，开场10分钟涌进来3万人。如果系统按3万并发做设计，成本极高；如果按平均值设计，那一刻就会崩。所以核心思路是**“前端削峰、后端排队、缓存抗量”**。

前端削峰：可以通过抢课页静态化、按钮置灰倒计时、请求随机延迟等方式，把瞬间请求打散。后端排队：用Redis的原子操作实现一个名额扣减服务，请求进来先过Redis校验名额是否充足，充足则进入消息队列异步创建订单，用户端轮询或WebSocket推送“抢课结果”。数据库层面，抢课请求不要直接打MySQL，否则行锁竞争和连接池打满会让整个系统雪崩。

我自己实践过的一套抢课小方案，代码逻辑很简单但实际效果很稳定：名额存在Redis的String里，用Lua脚本保证“判断剩余名额-扣减-记录用户”的原子性；扣减成功的请求进入RocketMQ，消费端（消费者组）负责创建订单和异步通知。这套方案在单Redis节点下能支撑每秒几千次的抢课请求，对绝大多数在线教育机构已经够用了。

这里有一个坑必须提醒：Redis扣减成功 ≠ 订单创建成功。如果消费端创建订单失败，名额已经扣了但用户没抢到课，需要做补偿。我比较推荐的设计是，在Redis里额外维护一个“已占用名额的待确认集合”，消费端把订单创建成功后，才把这个用户从待确认集合移到真正的报名名单。如果消费端超时失败，待确认集合里的名额可以由一个定时的对账任务进行释放。

4.2 视频播放的带宽与加载优化

视频播放是流量消耗的大头。一节45分钟的录播课，720P的HLS流大约在300MB左右。如果1000个学员同时看课，峰值带宽就按TB级别算，这个账单非常吓人。

节省带宽的核心手段有两个。一是转码输出多码率，播放器根据用户的网络带宽自动切换档位（自适应码率），让用户用最低可接受清晰度流畅观看，而不是全员挤在1080P。二是CDN命中率优化，热门课程的视频切片要保证CDN节点命中率高。实操里有个经验：如果播放器频繁请求同一个视频的不同参数（比如带不同的鉴权参数导致URL变化），CDN的缓存命中率会大幅下降。所以鉴权参数要设计成不影响CDN缓存的形态，尽量通过独立的鉴权接口返回播放凭证，而不是把凭证拼到视频URL里。

还有一处容易忽略：视频首帧加载速度。用户点开课程，最怕看到转圈。优化方案包括：播放器预加载（用户鼠标悬停在课程卡片时就开始拉取前几个切片）、首屏用低码率档位、HLS的切片长度控制在4-6秒等。首帧在2秒以内，基本就及格了。

4.3 直播间高并发与IM消息风暴

直播课的高并发跟录播课完全不同，它要求实时性。万人直播间的消息频道，每秒可能产生上千条聊天消息、弹幕和礼物特效。常规的HTTP轮询在这里毫无意义，必须走WebSocket长连接。

IM消息通道的架构核心是“消息总线 + 频道订阅”。每条消息进来后，先写消息队列，再由消息推送服务分发到对应频道的所有WebSocket连接。这里要注意，消息的存储与分发要解耦：存储是为了历史回放和敏感词审核，分发是为了实时到达，两者不能用同一套逻辑。

万人以上直播间，常见的处理手段包括：消息聚合（低价值消息按时间窗口合并，比如连续点赞每5秒展示“xxx等100人点赞”）、弹幕抽稀（对高频率弹幕做丢弃策略，保证不过载）、按房间分片（每个直播间是一个独立的消息频道，互不干扰）。IM服务还需要做消息的敏感词过滤，发送前先过一遍内容安全接口，正常业务语境下会大大减少后续的骚操作。

4.4 数据一致性：缓存与数据库的取舍

在线教育系统里，缓存与数据库的一致性问题主要出现在三个场景：课程详情页的状态展示、库存扣减、学习进度更新。

课程详情页的并发读远大于写，用Redis做缓存是必须的。但要注意缓存更新策略：课程信息变更后，主动删除缓存，等下一次查询回填新数据，比直接更新缓存更稳妥，能规避并发写导致的旧值覆盖。至于极端的缓存穿透（大量查询不存在的数据），可以用空值缓存加布隆过滤器挡在第一层。

学习进度的更新比较特殊，学员每5-10秒上报一次，数据库不可能承担这么高频的写。我的做法是：实时进度先写Redis，用Bitmaps结构或Hash结构存“课时ID + 用户ID + 进度点”，同时记录一个“是否上报过完成”的标记。学员完成课程（或退出课程）时，将Redis中的进度合并写回MySQL，并标记该课时已完成。这样既能做到断点续学秒级恢复，又不会把MySQL写爆。

5. 安全加固与合规运营的实操清单

5.1 系统安全的基础防线

安全这一节看着像标准动作，但我依然要单独拎出来，是因为在线教育系统属于“高价值数字资产”。课程版权、学员信息、交易数据，每一项丢了都是大事。

基础防线包含几层。传输层，全站HTTPS是必须的，这个没得商量。应用层，要防SQL注入、XSS攻击、CSRF攻击、越权访问。这里我想重点展开“越权访问”，因为在线教育系统里垂直越权（低权限用户访问高权限接口）和水平越权（访问同权限其他用户的数据）太常见了。尤其是学习记录和订单查询接口，必须做数据归属校验：后端不能信任前端传过来的用户ID或订单ID，要从登录态里获取当前用户身份，再校验目标数据是否属于该用户。

账号安全方面，要支持登录异常检测。比如同一账号在短期内不同IP、不同设备频繁登录，同一设备号注册了多个账号，同一IP批量注册等，这些异常行为最好有监控和自动拦截。黑灰产的攻击很多是自动化脚本，基础的频控和风控规则能挡掉大部分。

5.2 数据加密与隐私保护

用户数据保护，核心原则是“分级分类、按需加密”。手机号、身份证号、家庭住址这类敏感信息，在数据库里必须加密存储。常见做法是用AES-256加密存储，解密密钥放在独立的密钥管理系统里，应用层通过密钥服务接口获取，而不是把密钥硬编码在配置文件中。

手机号这类需要支持模糊搜索的字段，加密存储后会带来一个麻烦：没法用LIKE查询。实际做法往往是把手机号做“脱敏索引”——比如把138****1234的前三位后四位单独存成一个明文索引列，既支持按尾号搜索，又不泄露完整号码。至于身份证号，一般业务场景根本不需要展示完整号码，直接加密存储，仅提供脱敏展示即可。

日志链路也很关键。业务日志、操作日志、异常日志里如果打印了用户手机号、支付单号等敏感信息，那这些日志本身就变成了一个巨大的“数据泄露出口”。上线前要做一轮日志脱敏检查，把日志框架里的用户对象统一做序列化脱敏处理。

5.3 内容合规与安全审核

在线教育的内容审核，跟泛内容社区不太一样，但同样绕不开。老师上传的每一节课视频、课件、讲义，原则上都要经过审核后才能上架。视频可以通过云厂商的内容审核接口做自动机审（截帧识别违规画面、语音转文字后做文本审核），再配合人工抽检。这个流程不要省，尤其是有直播内容的平台，直播过程中的实时审核是硬指标。

文本内容（公告、帖子、问答、评价）也要做敏感词过滤和自动审核。这块国内有成熟的第三方内容安全服务，也有开源方案，但开源词库的更新速度和覆盖度经常不够，需要自己持续维护，我建议优先考虑与成熟的内容安全服务打配合。

5.4 业务合规运营要点

凡是涉及在线教育业务，就有几个合规底线必须在系统设计时预留位置。

教学资质与师资展示：系统要支持在显著位置展示机构的办学资质、讲师的教学资质信息。这个在页面设计与内容管理后台都应该提前铺好入口。

用户协议与隐私政策：注册环节的“同意用户协议和隐私政策”是强校验，不能默认勾选。隐私政策里要写清楚收集哪些信息、如何使用、如何注销账号。系统必须支持用户账号注销功能，注销后按约定删除或匿名化处理相关数据。

未成年保护：如果是K12业务，还要有未成年人保护相关的功能设计，包括防沉迷（学习时长提醒、夜间模式）、家长管控入口、未成年人信息保护的特殊规则。这些设计在业务早期不考虑，后期往往要伤筋动骨地改。

退款与投诉处理：系统要支持学员提交退款申请、机构审批、自动退款到账、投诉工单记录等完整闭环。退款规则与支付方式强相关，整个流程要有审计日志。这块对客服团队极其重要，也是监管纠纷时的重要数据支撑。

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

6.1 视频“转码中”状态卡死

这是我遇到最多的线上问题之一。老师上传视频后，状态一直卡在“转码中”。排查步骤按照这个顺序来比较高效：先看转码服务所在的任务队列有没有积压，再看媒体处理服务回调有没有正常到达后端，最后看后端处理回调的接口有没有报错日志。

常见原因往往是回调接口处理逻辑里的Bug，比如签名校验失败、回调数据解析异常、幂等表里存在冲突记录。所以转码回调接口上线前一定要做充分的测试：模拟回调成功、重复回调、回调超时、回调数据格式错误这几种情况。我遇到过最离谱的一次，是回调接口因为依赖的一个数据库字段命名错误，在特定条件下报了主键冲突，导致整个转码状态卡死。这种问题靠日志定位不难，难的是没有日志。所以转码状态流转的关键节点务必要打日志。

6.2 支付掉单

支付掉单就是“用户付了钱，但订单状态还是待支付”。排查步骤：先查支付平台的账单或订单详情，确认用户到底有没有支付成功。如果支付成功，再看回调记录有没有到达你的服务器，如果没到达，多半是回调地址配置错误或回调源IP白名单把支付平台的服务器挡了。如果回调到达了但没更新订单状态，那就是回调处理逻辑的问题。

我经历过一个比较隐蔽的掉单案例：支付回调正常，订单也更新为已支付，但用户提示“购买失败”，原因是订单更新事务跟课程权限开通事务没有放在同一个本地事务里，权限开通失败后没有回滚订单状态。这种问题在不做分布式事务的情况下，建议用“本地消息表”或“事务消息”来解决，确保“支付成功 → 订单更新 → 权限开通”三步的最终一致性。

6.3 直播黑屏或卡顿

直播卡顿的排查链路很长。先看是不是所有用户都卡，再看是不是某个区域或运营商段都卡，再看是不是只有某个老师开播时卡。如果所有用户卡，大概率是推流端的问题或源站带宽不足；如果部分地区卡，大概率是CDN节点覆盖或线路质量的问题；如果个别用户卡，大概率是用户本地网络的问题，这时可以建议用户切换网络或提供测速数据。

我遇到过一种情况：老师直播不卡，学生端大面积卡顿，根源是当时用了没有做多码率输出的直播方案，学生端统一拉着最高码率的流，有些低性能手机和弱网完全带不动。解决思路就是前面提到的双通道方案：普通观看走CDN直播，互动连麦走WebRTC低延迟通道。另外，直播课的录制回放要尽早生成，很多学员因为卡顿会直接放弃看直播，等回放。

6.4 App审核被拒的常见原因

很多在线教育产品会做App，上线应用商店时审核被拒是高频事件。最常踩的坑是：应用内没有提供用户注销账号的入口；权限申请时机不合理（比如一启动就申请相机和麦克风权限，而没有在具体使用场景时申请）；涉及在线教育但没有相关资质上传，或者资质信息与App内展示的机构信息不一致。

建议在开发初期就把这些合规细节列进需求清单，不要等审核被拒再回头补。另外，App内的用户协议和隐私政策链接必须能正常打开，支付流程要与App Store的审核规范保持一致，虚拟课程如果是内购项目，必须走苹果支付分成方案，这是底线。

6.5 高并发场景下的数据库连接池打满

抢课、秒杀这类场景，最容易把数据库连接池打满。表现是系统整体响应变慢，接口大面积超时。排查时第一眼要看连接池监控，确认是不是连接数飙升、活跃连接数接近最大值。常规优化有几步：确认数据库连接池配置的合理上限、对热门接口做Redis缓存或本地缓存兜底、慢SQL治理、把非关键路径的查询异步化。

一次实际的案例：某机构做限时拼团活动，活动页每个用户进入时都会查询一次“参团人数”用于展示拼团进度。表面上这是个小查询，但活动页被大量刷访问后，这个查询的TPS极高，最终拖垮了整个数据库。修复方案很简单：把参团人数放到Redis里，每2秒异步刷新一次。就这一行改动，数据库压力瞬间降了90%。这种问题在设计阶段就要警惕，只给用户看一个“接近实时”的数字即可，没必要求“绝对实时”——业务上完全感知不到差别。

7. 给不同角色的实操建议

这篇文章写到这儿，核心的技术框架、模块设计、性能方案和常见问题都已经铺开了。最后补一张实操建议表，给不同身份的读者一些可落地的参考。

在真正动手之前，多做一步功课：找同行业做得好的平台，把他们的课程详情页、购买流程、学习路径、直播课堂认真用一遍。这不是让你抄，而是让你感知成熟产品的信息架构，发现自己的业务在流程上的短板。在线课程系统定制开发这事，技术方案直接决定成本和上限，但真正决定项目成败的，往往是你对业务流程的梳理深度。

我个人这些年最深的体会是：定制开发最怕的就是“什么都想要”。需求越膨胀，系统越臃肿，最后连维护都无从下手。把核心路径上的体验做到极致，把运营需要的数据埋点做扎实，把权限和资金的合规底线守住，这套系统就能在很长时间里稳稳支撑业务增长。至于那些听起来炫酷但跟业务无关的功能，先放进需求池，等真正需要的时候再说。