在线课堂微信小程序毕设实战：Spring Boot全栈管理系统设计与实现

最近被问爆的一个毕业设计选题：“基于微信小程序实现在线课堂微信小程序管理系统【附项目源码+论文说明】”。这个标题几乎是每年毕设季的常客——它既不是纯前端页面堆砌，也不是一个后端接口集合，而是一套真正有业务闭环的完整系统：学生端、教师端、管理后台，再加一份能过审的论文。我带过的学员里，有不少人一开始只想着“做几个页面交差”，结果做着做着发现课程、签到、作业、后台管理全要打通，才意识到这个项目真正的难点不在页面数量，而在于业务链路能不能完整跑通。

这篇文章我就从需求拆解、技术选型、核心实现、论文包装、踩坑经验五个维度，把整个项目一条线讲清楚。无论你是拿来当毕设、课设，还是想自学一个全栈小程序项目，按这个思路走，至少能少走半个月弯路。咱们直接开讲。

1. 先搞明白：这个在线课堂管理系统到底要管什么

很多同学拿到题目就急着开写，我总会先按头让他们做一件事：把角色和业务模块拆清楚。这个系统既然叫“在线课堂管理系统”，核心不只是“在线课堂”，还有“管理”两个字。如果你只做一个小程序供学生浏览课程，那不叫管理系统，顶多算个展示页。

1.1 项目定位与角色拆解

在线课堂管理系统要解决的，是教学过程中的信息流转问题。老师要能发布课程、发起签到、布置作业；学生要能选课、看视频、完成签到、提交作业；管理员要能审核内容、管理用户、看运营数据。所以整个系统至少要有三类角色：

• 学生：从小程序端进入，完成注册登录后，可以浏览课程列表、查看课程详情、选课、播放视频、参与签到、提交作业、查看作业评分。
• 教师：负责课程内容维护，比如创建课程、管理章节、发起签到、布置作业、批改作业。教师端可以放在小程序里用“教师入口”切换身份实现，也可以做成后台的一部分。
• 管理员：通常用一个独立的Web管理后台来实现，负责用户管理、课程上下架、公告发布、数据统计等。

这里有同学会问：“那我的后端算什么？”后端是连接三端的公共层，所有端都调用同一套后端接口。你的小程序前端面学生，Web后台面管理员，教师端可以两处都做，或者单独在Web后台开放教师权限。角色划分直接决定数据库里的角色字段、接口的权限校验逻辑，以及论文里的用例图怎么画。

1.2 核心业务模块划分

按业务拆，我习惯这么切：

• 用户模块：微信授权登录、绑定手机号、角色区分、个人信息、账号状态管理。
• 课程模块：课程分类、课程列表、课程详情、章节管理、课程上下架。
• 教学互动模块：课堂签到、作业布置、作业提交、作业批改、学习公告。
• 选课/订单模块：免费课程直接选，付费课程可以模拟下单（毕设阶段不做真实支付），生成选课记录。
• 数据统计模块：用户数、课程数、播放量、选课人数、签到率、作业完成率。

拆完这些模块，你就能估算出大概需要多少个页面：小程序端至少有课程列表、课程详情、视频播放、签到、作业列表、作业提交、个人中心、登录引导，大概8到10个页面；Web后台至少要有登录、首页看板、用户管理、课程管理、作业管理、公告管理，再算上页面里的弹窗和表单，整体工作量差不多是三到四周的持续开发量。

这个模块划分也是你后面写“功能需求”章节的底稿。哪怕不画图，你也要用Word列一张“模块清单表”，答辩时老师一翻就能感受到你需求分析做得很扎实。

2. 技术选型不是随便选的：为什么是微信小程序+Spring Boot这套组合

在线课堂系统是个典型的全栈项目，技术选型直接决定开发体验和答辩时老师提问的深度。我看到不少方案是用“微信小程序云开发”，但其实从“管理系统”的角度看，独立后端才是更靠谱、更好写论文的路线。

2.1 前端：原生小程序还是uni-app

先解决最纠结的问题：原生小程序和uni-app二选一。

原生微信小程序的好处是没有任何框架包装，直接对着微信官方文档写WXML、WXSS、JS，所有API都是原生的，出问题时去搜索引擎一查，能搜到大量真实案例。坏处是列表渲染、自定义组件这些写起来比Vue繁琐一点点，但只要页面数量控制在15个以内，原生完全扛得住。

uni-app的好处是Vue语法，一套代码可以跑小程序、H5、App。但它的风险在于：如果你的Vue基础不牢，遇到问题时要多绕一层框架逻辑；而且某些视频播放、授权、文件选择这类微信原生功能，在uni-app里封装了一层，出问题不如原生好排查。

我个人的建议是：纯做微信小程序毕设，选原生。理由很简单：你要写论文，原生技术描述最准确，答辩被问“微信小程序的运行机制”时，你能聊得最细；uni-app更多是工作场景里为了跨端复用才选，放到毕设反而增加不确定因素。

2.2 后端：Spring Boot + MyBatis Plus几乎是最优解

管理系统的本质就是CURD，所以后端选型要看三点：资料多不多、上手快不快、能不能写清业务逻辑。Spring Boot加MyBatis Plus的组合，几乎是为这种课设项目量身定做的。

Spring Boot负责自动配置和接口暴露，内嵌Tomcat让你不用单独装Tomcat，一个Application类启动整个项目。MyBatis Plus把单表增删改查封装成现成方法，同时又保留XML自定义SQL的能力，遇到多表联查时你也能手动控制。这套组合还有一个隐性优势：能适配市面上90%的管理系统模板，以后你想做别的后台系统，思路直接复用。

接口格式我建议统一封装。比如你写一个Result类，里面就三个字段：code、msg、data。

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String msg) { Result<T> result = new Result<>(); result.setCode(code); result.setMsg(msg); return result; } }

小程序端每次请求后只要统一判断code，解析data，就能少写一堆重复的错误处理逻辑。

2.3 数据库设计要点：先把表关系画明白

数据库是评审老师必看的部分，也是很多人的重灾区。我整理一个最小可用版本的表清单，覆盖上述所有业务模块：

表设计有几个关键点：

• 用户和课程是多对多关系，必须用中间表，也就是student_course。
• 签到是一对多，一次签到有多条签到记录。
• 作业提交时要留成绩和评语两个字段，这样教师端才能批改。
• 所有业务表都要有创建时间和更新时间，方便你写统计功能。

物理外键可建可不建，但逻辑外键字段一定要写出来。论文里画ER图时，你至少要把表之间的关联线画清楚，这是答辩老师特别看重的细节。

3. 实操实现：从登录到课堂闭环的四个关键环节

这部分是整个项目最能体现价值的地方。我把整个系统最关键、也最容易出错的四个环节拆开来讲：登录授权、课程视频、签到作业、后台管理。每一步我都会说实际代码怎么落地。

3.1 微信登录与权限控制的完整链路

小程序登录和传统网页登录完全不同，走的是微信官方的code换openid流程。具体的链路：

1. 小程序端调用wx.login()，获取临时凭证code。
2. 通过wx.request把code发到后端接口，比如/user/login。
3. 后端收到code后，再拿appid+secret+code去请求https://api.weixin.qq.com/sns/jscode2session。
4. 微信返回openid和session_key，其中openid是用户在小程序里的唯一标识。
5. 后端根据openid查用户表，如果不存在就自动创建一个新用户，如果存在就直接返回登录成功。
6. 后端生成一个自定义token（最简单的是用UUID，也可以引入JWT），把token返回小程序端。
7. 小程序把token存进wx.setStorageSync('token', token)，后续所有请求在header里带token。
8. 后端做一个拦截器，固定的排除登录接口后，每个请求都检查header里的token，能取到用户信息就放行，取不到就返回401。

权限控制的简单做法是后端在需要限制角色的接口上，手动校验当前登录用户的role字段。比如新增课程需要教师或管理员角色，你就写一个工具方法判断：

if (!role.equals("teacher") && !role.equals("admin")) { return Result.error(403, "无权操作"); }

毕设阶段不需要引入Spring Security那么重的框架，但你必须让评委看到“用户不能越权调用接口”的保护逻辑。

这里有一个常见的坑：wx.login()返回的code是一次性的，用完就失效。有的同学为了省事，在前端把code缓存起来，第二次再拿去请求，结果微信服务端直接报错。你只需要每次调用登录函数时实时获取code就行，别做缓存。

3.2 课程列表与课程详情：视频点播怎么做

课程列表就是一个非常典型的列表接口：分页、条件查询、返回总数。小程序端用onPullDownRefresh做下拉刷新，用onReachBottom做触底加载，配合后端的分页参数pageNum和pageSize。最简单的实现是后端用MyBatis Plus的Page对象，直接返回分页结果。

课程详情的核心是章节列表和视频播放。视频这块我先给个结论：用微信内置的<video>组件就足够了，不需要额外接第三方播放器。

<video id="myVideo" src="{{videoUrl}}" controls enable-progress-gesture bindplay="onPlay" bindended="onEnded" ></video>

视频地址的来源有三种：

• 本地测试：把MP4放到Spring Boot的static/videos/目录下，通过http://localhost:8080/videos/xxx.mp4访问。
• 云存储：传到腾讯云COS或阿里云OSS，返回公网播放地址。
• 视频点播服务：用腾讯云VOD这类产品，功能强，但毕设阶段有点杀鸡用牛刀。

本地测试的状态下，小程序开发者工具要勾选“不校验合法域名”才能访问。但手机预览时这个设置不生效，手机访问不到localhost。所以等你要演示时，要么把视频放到云存储，要么把整个后端部署到云服务器并用公网IP访问，否则手机端会播放失败。

继续播和章节完成态是两个很好的加分功能。你可以在bindended事件里调用后端接口，把视频章节标记为“已完成”；在页面加载时读取历史播放进度，用wx.createVideoContext('myVideo').seek(seconds)跳转。这两个点写在论文和答辩里，会明显比别人的“只给一个视频链接”高一个档次。

3.3 课堂互动：签到、作业、讨论的实现思路

签到的逻辑不复杂，但考的是业务细节。一个完整的签到功能包括：

• 教师在前端页面创建签到活动，传入课程id、开始时间、结束时间。
• 学生在小程序里查看当前课程有没有进行中的签到。
• 学生点击“签到”，后端判断当前时间是否在startTime和endTime之间。
• 如果有效，就插入一条签到记录sign_record，并把学生状态标记为已签到。
• 同一个签到活动，一个学生只允许签一次，用唯一索引或前端防重。

防作弊可以做一个可选加强：学生签到时回传经纬度，后端计算与课程发布位置的距离，超过设定阈值就拒绝签到。这一步实现不算难，但答辩时能成为你的一个亮点。

作业模块是另一个闭环：教师创建作业，学生提交作业，教师批改并给分，学生看评分。上传文件的实现是重点，小程序不能像普通网页那样直接POST一个文件对象，要用wx.uploadFile接口：

wx.uploadFile({ url: 'http://localhost:8080/api/homework/submit', filePath: filePath, name: 'file', formData: { homeworkId: homeworkId, studentId: studentId }, success(res) { const data = JSON.parse(res.data); if (data.code === 200) { wx.showToast({ title: '提交成功' }); } } });

后端接收multipart文件后，把文件保存到本地目录或云存储，再把访问URL和作业id一起写进homework_submit表。后续教师批改时，只需要读取这条记录的file_url下载或预览即可。

3.4 管理后台：数据看板与内容审核

管理后台建议用Vue3加Element Plus来写。不要觉得再学一个框架麻烦，Element Plus的表格、表单、弹窗组件已经封装得很好，你只需要把后端返回的数据填进表格即可。

后台页面最低要求是这些：

• 登录页：管理员账号密码登录，登录成功后用token存身份，路由守卫检查角色。
• 首页看板：放几个统计卡片，然后可以用ECharts画一个折线图展示近7天的课程播放量或者用户增长曲线。
• 用户管理：用户列表、搜索、禁用/启用账号。
• 课程管理：课程列表、上架/下架、编辑。
• 作业管理：查看各课程作业的提交情况、给分、写评语。
• 公告管理：发布公告列表、新增公告。

后端的接口建议用/admin/**前缀和小程序的/user/**或/api/**区分开，再写一个专门拦截/admin/**的HandlerInterceptor，只允许admin角色访问。这样管理端权限和小程序端权限互不干扰，结构很清晰。

4. 源码+论文的“交付物”思路：毕业设计怎么包装才不翻车

这个标题里特别标注了“附项目源码+论文说明”，说明你意识到了交付物的重要性。代码能跑只是及格线，论文写得像样、源码组织清晰，才是拿高分的关键。我根据自己的评审视角，把这部分拆成源码组织、论文写法、答辩准备三个点。

4.1 源码结构怎么组织才加分

很多人的源码里，前端后端混在一个压缩包里，数据库脚本放桌面，论文单独一个文档，名字还取“最终版2（改）”。这种交付方式其实很吃亏。我习惯交付时就整理成一份标准目录：

online-classroom/ ├── miniprogram/ # 微信小程序前端 │ ├── pages/ │ ├── components/ │ ├── utils/ │ ├── app.js │ └── app.json ├── server/ # 后端工程 │ ├── src/main/java/com/xxx/ │ │ ├── controller/ │ │ ├── service/ │ │ ├── mapper/ │ │ ├── entity/ │ │ ├── config/ │ │ └── common/ │ ├── src/main/resources/ │ └── pom.xml ├── sql/ │ └── online_classroom.sql ├── docs/ │ ├── 论文.docx │ ├── 答辩PPT.pptx │ └── 演示录屏.mp4 └── README.md

重点说一下README.md，这是很多人忽略的加分项。里面写清楚：系统环境要求（JDK版本、MySQL版本、微信开发者工具版本）、启动步骤（先建库、导入SQL、改数据库配置、启动后端、导入小程序、修改appid）、默认测试账号（学生、教师、管理员各一个）。评委拿到你的项目后十分钟内能跑起来，印象分会直接拉满。

4.2 论文怎么写：目录骨架、图表要求和查重避雷

论文目录我建议严格按这个骨架走：

• 第一章 绪论：研究背景与意义、国内外研究现状、研究内容、论文结构。
• 第二章 相关技术介绍：微信小程序、Spring Boot、MyBatis Plus、MySQL、Vue3（如涉及后台）。
• 第三章 系统分析：可行性分析、需求分析、角色分析、功能需求分析、非功能需求分析。
• 第四章 系统设计：系统总体架构、功能模块设计、数据库设计、接口设计。
• 第五章 系统实现：各个功能模块的实现过程，关键代码贴出来并说明设计思路。
• 第六章 系统测试：测试环境、测试用例表、功能测试结果、性能简单测试。
• 第七章 总结与展望：总结自己完成的工作，指出不足和后续优化点。

查重的最大来源是“相关技术介绍”跟“系统实现”这两章。很多学生直接复制百度百科和博客文章，结果重复率飙到40%。正确的做法是，用你自己的项目语境来重述技术点。比如写微信小程序，不要写“微信小程序是腾讯推出的一种应用形态”，而要写“本系统选用微信小程序作为学生端载体，理由是其无需安装、使用门槛低，并且通过微信官方提供的API可以实现登录和内容交互”。把技术介绍和你的项目选择结合在一起，既原创又好理解。

图表方面必须要有：系统功能结构图、系统架构图、ER图、主要流程图、运行效果截图。截图建议每张配一个图题和一段简短的实现说明，比如“图5-3 学生课程列表界面，该页面通过调用CourseController中的listCourse()方法获取数据，并通过setData渲染到小程序视图层”。写到这里，答辩时老师问“这个页面怎么实现的”你就有据可答了。

4.3 答辩常见问法：项目亮点、数据库关系、用户并发

答辩时间通常很紧凑，问题往往集中在几个固定方向：

• “你觉得这个项目最大的亮点是什么？” 别说“我用了微信小程序+Spring Boot”，这是技术，不是亮点。你最好提一个具体的业务设计，比如“实现了签到距离限制”“课程播放完成状态记录”“教师端作业批改闭环”。如果实在没有，就说“角色权限划分比较清晰，前端、后端、数据库三层结构完整，整个选课到作业的流程是闭环的”。
• “这三个表之间是什么关系？” 说清楚user和course是多对多，通过student_course连接；course和course_section是一对多；homework和homework_submit是一对多。这些基础关系必须答得快。
• “如果用户量变大，系统哪里会成为瓶颈？” 你可以说课程列表查询会变慢，需要加Redis缓存；视频文件不应该放在本地服务器，要上云存储和CDN；数据库要加索引，重要的统计查询要拆分。哪怕你没有实际做过，说出方向也是加分项。
• “为什么用MyBatis Plus不用JPA？” 你可以说MyBatis Plus保留了SQL的可控性，单表操作封装简洁，原生的XML写多表联查更直观，熟悉Java开发的同学上手更快。这段提前背熟，准确率会高很多。

5. 经验复盘：做过这个项目后，才敢说的避坑清单

最后这部分不算教程，是踩出来的经验。我自己带项目和帮人debug过程中，反复出现的问题就那么几个。提前列出来，能帮你省下大量排查时间。

5.1 小程序审核、云开发与独立后端的取舍

如果你这个项目将来真的要发布上线，微信小程序个人主体无法通过“在线教育”类目的审核，必须用企业主体，并且要配备相应的教育资质。但对于毕设而言，在开发者工具里跑通、用真机预览演示，已经足够。所以不要为了“上线”去申请各种账号资质，那是另一个阶段的事，论文里写一句“目前系统处于本地部署演示阶段，后续可迁移至云服务器并接入正式域名”就够了。

云开发和独立后端之间，如果你对后端感兴趣或想体现数据库设计能力，一定选独立后端。云开发虽然省了服务器，但云函数的调试链路长、内存限制多、数据导入导出不如本地MySQL方便。更重要的是，评审老师倾向于看到你亲手设计的数据库表结构和后端接口，而不是一堆“云函数”黑盒。

5.2 视频播放、缓存、流量那些坑

视频播放最大的坑就是编码格式不匹配。有些MP4是H.265编码，安卓小程序上会黑屏或者只有声音没有画面。建议统一转为H.264编码的MP4再放上去，这个用格式工厂或者ffmpeg一行命令就能解决。

第二个坑是视频地址不能是localhost。手机预览时根本无法访问你电脑上的localhost地址，这也是很多同学在本地开发工具里跑得好好的，一手机预览就废掉的原因。解决方法是：项目演示前，把视频文件传到云存储，获得公网地址；或者把Spring Boot部署到云服务器，用服务器IP访问。后端接口同理，手机预览时wx.request的域名要改成局域网IP或者公网地址，而且要保证手机和电脑在同一个网络下（如果走局域网IP）。

流量方面，小程序里反复播放视频会消耗用户很多流量，也影响体验。你可以在接口里设计一个lastPlayTime字段，每次暂停或退出时记录播放进度，下次再进入自动续播。这既是一种用户体验优化，也是避免重复拉流的手段。

5.3 给初学者的调试建议

和本地后端联调时，最常见的问题是小程序请求报“url not in domain list”。开发时在开发者工具右上角“详情—本地设置—勾选不校验合法域名”可以解决。但如果你用手机预览，这个选项不会自动生效，需要在后端配置一个合法域名。没有域名的，可以临时用局域网IP测试，或者把后端部署到有公网IP的测试服务器。

另一个常见问题是“接口返回数据但页面没渲染”。多半是数据层级没对上。后端返回给前端的是一个{code, msg, data}的结构，小程序端取数据要res.data.data，很多同学习惯性只在第一个data停住。建议在request.js里统一对返回数据做处理，直接resolve出data.data，再返回页面使用，这样页面里就不会到处出现两个data了。

调试技巧方面，一定要习惯看开发者工具的Network面板。我之前帮人排查问题时，发现很多人只看console，不看请求详情。其实接口的成功与否、返回了什么、请求体是什么，在Network里一眼就能看清。遇到404就从路径和请求方式找问题；遇到500就从后端日志找问题；遇到401就查token和拦截器。熟练了以后，排查问题的速度能快一倍。

最后分享一个小小的治懒习惯：项目里所有接口地址统一放到utils/config.js里，并且根据环境切换baseURL。

const BASE_URL = 'http://localhost:8080'; module.exports = { BASE_URL };

然后utils/request.js里统一封装get和post方法，每次请求前自动带token，每次返回后统一判断code。这样到了后面部署到服务器，只需要改config一个文件就行，不用全项目搜wx.request。所有小程序项目都适用这个套路。

这个项目要说难，其实没有哪个单独的技术点能难倒人；要说简单，把选课、签到、作业、统计全链路做透，也真不是敲一两天代码的事。我自己的体会是，这类管理系统最怕的不是写不完，而是前期需求没理顺，做到中间才发现表结构不合理，又回头改数据库，整个进度全崩。所以如果你准备做，一定先花半天把想明白“谁在用、用什么功能、数据怎么流动”这三件事，再动手。

这篇文章里的表结构和接口思路，基本都是我从实际项目里反复调整后沉淀下来的方案，直接照抄框架没问题。但真正的好项目，一定是你在这个基础上，加点自己的小创新——不管是签到定位、视频续播，还是数据看板，都能让你在答辩时多一份底气。希望这次拆解，能让你少走几天弯路。