★ FEATURED ARTICLE 在线课堂这类项目这两年我经手了不少但每次看到“微信小程序SSM”这种组合还是觉得挺有意思。它不是那种纯前端展示的玩具项目也不是重后端的企业级平台而是刚好卡在很多开发者、毕业生和初创团队最需要的那条线上前端用微信小程序触达用户后端用SSM撑起业务逻辑中间再补上文档和源码基本就是一个完整可落地的学习类产品闭环。这个项目标题里藏着的信息量其实不小。微信小程序意味着轻量、即用即走、依托微信生态SSM则对应着成熟的Java技术栈职责清晰、资料多、招人好招。两者拼在一起就是一个典型的“移动端展示服务端管理”的在线教育解决方案。今天我就以这套在线课堂项目为蓝本从架构、功能、实操到排坑完整拆一遍说说这东西到底怎么落地。1. 项目整体构思与设计思路拆解1.1 为什么是“微信小程序SSM”这对组合先说选型。很多人一上来就纠结用不用Spring Boot或者要不要上Vue3全家桶其实在这个项目场景里SSM才是更稳妥的答案。SSM指Spring SpringMVC MyBatis它解决了三件事Spring管对象、SpringMVC管请求、MyBatis管数据库。对于在线课堂这种业务——课程管理、用户登录、订单支付、视频播放记录——它的分层足够清晰Controller只接收参数和返回JSONService处理业务规则Mapper操作MySQL任何一环出问题都能快速定位。更重要的是SSM项目的学习资料、代码风格、招聘需求都高度统一你写出来的项目别人接手成本低做课程设计也好、毕设也好、内部系统也罢都好交代。微信小程序这边优势就更直接了。用户不用下载App扫个码就能进课堂页面天然适合“碎片时间学习”这个场景。再配合微信支付、订阅消息、分享裂变这些能力获客路径非常短。相比开发原生Android/iOS两端小程序只需要一套代码审核周期短、迭代速度快对于中小型在线教育团队来说是性价比最高的起点。1.2 项目功能模块与业务闭环设计这个在线课堂项目不是简单的“展示课程视频”这么单薄它要撑起一个完整的业务闭环大致可以分成四个模块用户端小程序注册登录、浏览课程、搜索筛选、课程详情、下单购买、视频播放、评价收藏、个人中心。讲师/管理后台课程发布与管理、章节内容维护、订单查询、用户管理、数据统计、评论审核。公共能力微信登录鉴权、微信支付、对象存储服务保存视频和封面图、消息推送。数据库用户表、课程表、章节表、订单表、评论表、收藏表、分类表外加管理员表。这四个模块串起来就是一条主线用户进来看到课程列表点进详情了解大纲和讲师信息决定购买后走微信支付支付成功解锁视频学完写评价后台看数据做运营调整。整个流程没有任何断点这才算是一个能上线的项目而不是一堆CRUD拼凑的“假工程”。1.3 前后端交互的接口约定与数据流在线课堂项目的前后端交互核心就是RESTful接口加JSON数据。小程序端通过wx.request发起请求后端接口返回统一格式的数据结构。我之前做这类项目时会强制规定所有接口的响应格式{ code: 200, message: 操作成功, data: { courseId: 1, courseName: Spring Boot实战课, teacherName: 王老师 } }code为200时前端正常解析data非200时弹出message提示。这种约定看着简单但能避免前端写大量判空逻辑也方便后端统一处理异常和事务。数据流上前端不直接操作数据库所有请求通过HTTPS到后端接口后端再通过MyBatis操作MySQL。涉及文件上传比如讲师上传课程封面走独立的上传接口返回URL后前端和其他接口配合使用。2. 核心功能模块细节与实操要点2.1 用户登录与手机号获取方案在线课堂项目里登录是第一个门槛。微信小程序的登录流程官方推荐的做法是前端调用wx.login()获取临时code。将code发送到后端后端通过code换取openid和session_key需要调用微信接口。后端以自己的token机制返回一个登录凭证给前端后续请求都带着这个凭证。这里有一个容易踩的坑不要把openid直接当作登录凭证暴露给前端。openid是用户的唯一标识但一旦泄露别人可以伪装身份。正确做法是后端生成一个UUID或者JWT作为token在Redis或数据库里建立token与用户实体的映射并设置过期时间。再说获取手机号。很多在线课堂为了简化注册流程直接用“微信手机号快速验证组件”一键拉取用户手机号。这个组件用起来很简单前端调用后获取到code再把code发给后端解密得到手机号。实操中有两个注意点该能力需要小程序绑定非个人主体且类目资质符合要求。个人开发者账号基本用不了做项目前先确认主体类型。手机号获取后建议把手机号明文脱敏存储日志里也不要打印完整手机号避免信息泄露。2.2 课程列表与搜索筛选设计课程列表页面是用户进入后的第一屏这块直接决定用户体验。我建议列表页不只做简单的分页拉取还要支持多条件筛选。分类按“前端、后端、移动端、AI、职场技能”等划分排序支持“最新上架”和“销量最高”价格区间筛选可以做成滑块组件。后端对应的接口一般是这样的GET /api/course/list?categoryId1keywordSpringsortlatestpage1pageSize10实现时要注意SQL的写法。如果keyword不为空就拼LIKE条件如果categoryId不为空就加等值条件。这里最忌讳的是把所有查询条件写死成一个SQL每来一个需求改一次Mapper。规范的写法是用MyBatis的动态SQLif标签或者用QueryWrapper这类方式让条件拼接可控。列表接口返回的课程卡片一般包含课程封面图、课程名称、讲师昵称、价格、销量、评分。封面图建议压缩成适合列表展示的尺寸比如750x422不要直接丢原图否则在小程序里加载会很慢。2.3 视频播放与章节解锁的核心逻辑在线课堂里视频播放是业务核心。和普通视频网站不一样这里必须处理“学员权限”问题——买了课程才能看完整视频没买只能看试看章节。我的实现思路是章节表里加一个字段isFree0收费1免费视频播放页加载时先判断当前用户是否购买了该课程。如果购买了返回全部章节播放地址如果没买只返回isFree1的章节地址。前端拿到播放地址后通过video组件进行播放。这里补充一个之前做项目时踩过的坑小程序video组件的播放地址必须是HTTPS协议而且域名需要在小程序后台的“request合法域名”和“业务域名”里配置。如果视频存放在阿里云OSS或腾讯云COS上记得开启HTTPS访问同时配置好跨域和防盗链否则Android端可能播放正常、iOS端却黑屏。另一个细节是播放进度记录。用户看到一半退出下次进来应该接着播。实现方式是视频播放过程中定时上报进度比如每15秒上报一次后端存到learning_record表。再次打开播放页时请求该用户对当前章节的观看进度然后通过video组件的initial-time属性指定起始播放位置。2.4 订单生成与微信支付接入流程下单和支付是另一个重点环节。整个流程建议严格遵循以下顺序用户点击“立即购买”前端向后端发起下单请求。后端校验课程状态、用户是否已购买生成订单记录status待支付。后端调用微信支付统一下单接口传入订单号、金额、openid、回调地址等参数。微信支付返回prepay_id后端把它封装成小程序端需要的paySign等参数返回给前端。前端调用wx.requestPayment拉起收银台。用户输入密码支付成功微信服务器异步回调后端通知接口后端更新订单状态为已支付并给用户开通课程权限。整个链路中最容易出问题的环节就是回调。回调接口必须是公网可访问的HTTPS地址而且要处理“重复通知”的情况——微信支付在极端情况下会多次回调后端必须做幂等处理也就是判断订单是否已支付已支付就直接返回成功不做重复操作。订单金额不要在前端传给后端必须由后端基于课程价格计算。这一点是老生常谈了但还是有人图省事把价格参数直接带在接口里结果被刷单。3. 后端SSM工程搭建与关键实现3.1 数据库表设计要点在线课堂项目的表设计我建议重点做这几张表user用户基础信息openid、昵称、头像、手机号、注册时间。teacher讲师信息姓名、简介、头像、擅长方向与user可以是一对一关系。course课程主体标题、封面、价格、分类、讲师ID、总章节数、销量、评分。course_chapter课程章节课程ID、章节序号、标题、视频URL、是否免费、时长。course_order订单订单号、用户ID、课程ID、金额、支付状态、支付时间。course_comment评论用户ID、课程ID、评分、内容、创建时间。course_favorite收藏用户ID、课程ID、创建时间。这里说一个设计细节课程价格建议用分int类型存储不要用float或者double。比如99元存9900分。原因很简单浮点运算在金额计算上会有精度问题微信支付金额的单位本身就是分你用int存储完全对齐后续对账也方便。另外全部表都要加create_time和update_time字段。这是最基本的习惯但后台统计数据和排查问题的时候没了这两个字段会非常痛苦。3.2 Controller、Service、Mapper三层的职责分离SSM项目最核心的就是分层思想。我见过很多新手的代码一个Controller里既写业务逻辑又拼SQL看起来也没啥大毛病但一旦需求变化改动起来就是“牵一发动全身”测试都没法做。规范的做法是Controller层只做参数接收和结果返回参数校验可以放在这一层用Valid注解搞定。Service层写业务规则比如“下单前判库存”“支付成功后开通权限”业务方法上加上Transactional保证事务。Mapper层只负责数据库操作复杂SQL写到XML里严禁在Java代码里拼接SQL字符串。举个例子用户购买课程的Service方法大概是这样Override Transactional(rollbackFor Exception.class) public OrderResult createOrder(Long userId, Long courseId) { // 1. 查看用户是否已购买 CourseOrder existing orderMapper.selectByUserIdAndCourseId(userId, courseId); if (existing ! null existing.getStatus() 1) { throw new BusinessException(您已购买过该课程); } // 2. 查询课程信息计算金额 Course course courseMapper.selectByPrimaryKey(courseId); if (course null) { throw new BusinessException(课程不存在); } // 3. 创建订单记录 CourseOrder order new CourseOrder(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setCourseId(courseId); order.setAmount(course.getPrice()); order.setStatus(0); orderMapper.insert(order); return buildResult(order); }事务注解必须加在Service方法上而且锁的范围要合理。如果方法里既有查询又有写入要么用行锁SELECT ... FOR UPDATE要么依赖唯一索引去重否则并发下可能出现重复订单。3.3 接口安全与异常统一处理在线课堂虽然不算高安全敏感系统但接口安全不能完全不做。至少这几点要有敏感接口校验登录状态。写一个拦截器检查请求头里的token解析到用户信息后放入ThreadLocal或request attribute后续逻辑直接使用。统一异常处理。用ControllerAdvice捕获全局异常业务异常返回对应code系统异常统一记日志并返回友好提示不要直接把堆栈信息抛给前端。简单防刷。下单接口、发送验证码接口做频次限制比如同用户1秒内只能请求一次。可以用Redis的INCREXPIRE实现个简单的滑动窗口。统一异常处理这块我的做法是定义一个BusinessException业务代码里主动抛出。全局异常处理器捕获后返回统一格式前端拿到非200的code就能弹出后端提示不用再额外做错误映射。3.4 文件上传与静态资源访问课程封面、讲师头像、课程视频都属于文件上传。之前做SSM项目时文件上传都是写到本地磁盘但在线课堂这种场景我强烈建议使用对象存储。以阿里云OSS为例后台上传接口接收MultipartFile然后以“课程ID/时间戳/文件名”的路径存入OSS返回公网URL。注意设置OSS的CORS规则允许小程序端跨域读取同时开启CDN加速视频播放会更流畅。如果只是想本地开发测试也可以配置本地存储路径并让SpringMVC的静态资源映射指向该目录。但生产环境一定要用云存储否则服务器带宽扛不住视频消耗而且重启服务器文件可能丢失。4. 小程序端开发的关键细节与避坑记录4.1 自定义顶部导航栏高度适配小程序开发里一个让人头大的问题就是顶部导航栏的高度。设计稿上写着“顶部留白多少px”结果换了手机就变样。这个问题的根本原因在于不同机型的刘海屏、状态栏高度不一致原生导航栏的胶囊按钮位置也不同。解决办法是自定义导航栏也就是在小程序页面的json配置里设置navigationStyle: custom然后通过wx.getSystemInfoSync()拿到状态栏高度const systemInfo wx.getSystemInfoSync(); this.setData({ statusBarHeight: systemInfo.statusBarHeight, navBarHeight: 44 // 常规导航栏高度 });多数情况下状态栏是20~50像素不等胶囊按钮距离状态栏底约10px。你可以用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的准确位置再算出导航栏总高度。这样适配下来不管什么机型页面布局都能对齐。4.2 小程序登录与token管理前端登录逻辑虽然简单但要写规范了也不容易。我的建议是做一个全局的登录封装App启动时检查本地是否有token有且未过期直接用没有则走wx.login静默登录。请求封装统一在wx.request外面包一层自动带上token并统一处理401token失效跳转登录页。登录态过期时不要直接弹“登录已过期”了事最好静默重新登录后重发原请求减少用户打断。一点小细节token过期时间不宜太长建议7天。到期后让用户重新静默登录不需要输入账号密码体验没有影响。如果涉及支付、写操作等敏感场景重新登录时最好要求用户再验证一次手机号。4.3 性能优化与首屏加载在线课堂小程序要面对的是课程列表这种图片多、数据量大的页面性能优化必须从第一天就关注。我的实操经验集中在三点第一图片务必使用懒加载。小程序image组件有个lazy-load属性开启后只有在图片进入视口时才加载列表页滑起来明显更流畅。第二控制单次接口返回数据量。列表接口分页大小建议10~20条不要一次返回几百条。后端再配合分页查询前端上拉加载更多时追加渲染避免setData大对象导致的卡顿。第三setData操作要精简。小程序的setData是数据驱动的渲染数据量过大会导致页面卡顿。复杂对象只更新变化的字段不要整页数据全量setData。比如点赞后只需要setData({likeStatus: 1, likeCount: count1})而不是重新拉一次详情。4.4 微信支付的前端流程处理前端拉起微信支付时最怕的是用户“看到弹窗就锁屏”或者“支付过程中切后台”。这两种情况下支付结果不一定会及时回传前端所以前端要做一下兜底wx.requestPayment的fail回调不要直接提示“支付失败”。先调用后端查询订单状态接口如果实际已支付告诉用户“支付已成功正在开通课程”。支付成功后不要马上跳转等后端开通权限接口返回成功后再跳转课程详情。如果支付过程中卡住提供“重新检测”按钮本质上还是查单。这个细节处理好了能减少很多售后投诉用户会认为这套系统很稳定。5. 常见问题与排查技巧实录5.1 微信小程序认证与类目资质问题在线课堂这类涉及“在线教育”的小程序发布上线前要过微信的类目审核。个人主体的小程序基本做不了付费课程需要企业主体且具备教育类资质同时微信认证每年的费用和审核材料要提前备齐。实际操作中我的建议是开发阶段用测试号无所谓但上线前一定要先去小程序后台确认类目否则审核被拒一次就要浪费好几天。另外如果涉及虚拟支付课程属于虚拟商品还要注意微信对iOS端虚拟商品支付的限制规则避免上线后功能被折叠。5.2 支付回调收不到或重复通知支付回调问题是我排查次数最多的问题之一。常见原因有回调URL配置错误或域名没有备案。微信支付要求回调地址必须是HTTPS且域名已备案。本地开发时可以用内网穿透工具把本机服务暴露到公网调试回调很方便但生产环境不要这么干。回调处理中出现了异常但接口没返回成功标识。微信在规定时间内收不到成功响应会持续重试所以回调接口一定要catch所有异常即使业务处理失败也要返回成功给微信然后记录日志手动补单或者明确返回错误让微信后续重试。回调里签名校验失败。支付回调通知里有sign字段后端需要用APIv3密钥或APIv2密钥验签验签失败要拒绝处理并记录日志。常见坑是密钥配置错误或者参数拼装顺序不对。5.3 小程序端网络请求失败与域名白名单开发时经常遇到一个情况预览工具里请求正常真机上一请求就报“url not in domain list”。这是因为小程序真机环境对域名做了严格校验开发阶段可以在小程序后台设置“不校验合法域名”但上线前必须把所有接口域名和文件域名都配置到白名单。需要注意的有两类一类是request合法域名对应后端接口另一类是downloadFile合法域名对应视频和图片资源。如果视频播放地址和接口域名不一致都要逐个加白。之前一个项目漏配了视频域名结果测试环境看着好好的一上线播放页直接黑屏。5.4 视频播放卡顿与兼容性在线课堂项目上线后反馈最集中的问题就是视频卡顿。这个问题的根源通常不在后端代码而在视频编码和传输链路。我的建议是视频文件统一转成H.264编码、AAC音频、MP4封装格式码率压到合理范围720P约1.5Mbps。如果视频源是用户自己上传的后端要接一个转码服务不要直接原封不动地用上传文件做播放源。播放策略上优先用微信小程序的video组件配合腾讯云点播或阿里云视频点播服务它们自带多码率自适应会根据用户带宽自动切换清晰度远比你自己裸放MP4文件靠谱。5.5 数据一致性与重复开通权限支付回调成功和页面主动查单成功这两条路径都可能触发“开通课程权限”。如果实现不严谨用户可能收到两条开通逻辑虽然显示上没毛病但后台可能出现重复记录。解决办法是在权限表course_user里加唯一索引user_id, course_id插入时用INSERT IGNORE或者先查后插。同时在开通逻辑里加上分布式锁或事务控制保证同一用户同一课程的并发开通只有一次有效。这个小细节用得好是加分的用不好就是线上事故。6. 部署上线与后续扩展建议6.1 环境准备与部署流程在线课堂这类项目的部署我按步骤拆成四块服务器准备一台2核4G的云服务器起步带宽建议5Mbps以上。操作系统选CentOS 7或Ubuntu装好JDK8以上、Tomcat或直接打成jar包跑Spring Boot虽然项目是SSM但用Spring Boot启动也能兼容整合。数据库部署MySQL 8.0字符集utf8mb4设置好备份策略。数据库上云的话用云数据库RDS更省心自动主备切换不用自己操心跳和管理工具。对象存储与CDN视频和图片放在OSS/COS上开CDN加速。这一步别省用户遍布全国各地一个源站扛不住跨地域的带宽压力。域名与HTTPS申请域名并备案配置Nginx反向代理把后端接口暴露为https://api.xxx.com再挂证书。小程序的request合法域名和业务域名都填这个。部署过程中我遇到过最玄学的问题是Nginx配置反向代理后小程序请求出现“502 Bad Gateway”。排查后发现是后端服务启动较慢Nginx在等待后端响应时超时了。解决办法是修改proxy_read_timeout和proxy_send_timeout参数调大到60秒以上同时确认后端服务的keepalive和线程池配置没有瓶颈。6.2 项目后续功能扩展方向如果这个在线课堂项目要往更完整的方向迭代我建议优先补这几个能力第一运营侧增加优惠券系统。购买页可以输入兑换码或者选择满减券提升转化率。表结构上新增coupon和user_coupon两张表即可核心逻辑在结算时校验。第二内容侧增加限时免费、拼团、分销裂变。拼团适合社群运营分销可以设置为“老带新返现”这块做起来要小心合规但确实是拉新利器。第三学习侧增加学习计划、打卡提醒、课程证书。教育产品的护城河是学习效果让用户能感知到“我学了多少”留存才有意义。基于现有learning_record表做学习统计、周报推送、证书生成都不难。第四管理端做成Web后台用VueElement Plus与后端SSM对接。后台功能包括课程审核、讲师入驻审核、订单退款处理、财务对账、用户行为分析。这一层做完项目才真正具备商业运营的雏形。6.3 源码与文档的维护建议这个项目代号里带着“文档源码”说明对工程规范和资料完整性的要求很高。我的习惯是每个模块建一个独立的包包名和表名一一对应别人拿到代码后扫一眼结构就懂业务。README里写清楚环境要求、数据库初始化脚本、配置修改说明、接口文档地址。最好再配一份部署文档从购买服务器到线上发布一页纸能看完。接口文档建议用Swagger或Apifox导出标注好每个字段的含义和取值范围避免前后端在联调时反复扯皮。源码的Git管理从第一天就做每个功能一个分支合并时写清楚commit message。别等到项目快发布才想起Git那时候文件和功能早乱成一锅粥了。一套在线课堂系统做到这个深度已经能应付绝大多数真实业务场景。小程序端流畅、后台稳健、支付闭环不出错、文档清晰可交付这才是一个能拿得出手的项目。我在实际开发中还有一个体会做这种全栈项目最容易翻车的不是技术难度而是沟通成本。接口文档写得模糊、状态码含义不统一、日志打得乱七八糟这些才是拖慢进度的隐形杀手。如果让我带新人走一遍这个项目我会让他先把后端接口定义写完前端照着文档开发联调基本都是顺的。先定规矩再写代码开发效率至少提升一半。最后再分享一个细节技巧给这个项目配一个统一的口径所有接口的返回结构、所有表格的逻辑删除字段、所有管理员的权限点都尽量保持一致的命名规则。这样无论是你做二次开发还是请同事接手都不会有“这代码怎么风格都不一样”的崩溃感。项目做久了你会明白规范不是死板的约束而是让工程质量逐步提升的最省力路径。
阅读完成 · 觉得有帮助？
