SpringBoot+Vue3+UniApp多端网络课程系统开发实战复盘

标题里提到的这套系统，我是从一次实际的咨询需求入手的。某高校信息中心想搭建一套网络课程信息管理系统，要求是既有给管理员用的Web后台，又能让学生在小程序里看课、选课、跟进度。技术栈指定了Java生态，前端要能覆盖管理端和学生端。当时市面上现成的在线教育系统不少，但定制成本、部署复杂度、二次开发的自由度都是问题，最后我们决定基于 SpringBoot + Vue3 + UniApp 从零搭一套。这篇博文就把整个项目的选型思路、数据库设计、前后端实现、部署避坑完整复盘一遍，适合已经掌握 Java 和 Vue 基础知识、想独立完成一个多端项目的开发者参考。

1. 技术选型复盘：SpringBoot + Vue3 + UniApp 这套组合是怎么定的

1.1 为什么不用SSM直出页面，而是走前后端分离

项目标题里同时提到SpringBoot和SSM，其实这两者不是对立关系。SSM（Spring + SpringMVC + MyBatis）是更早的经典组合，SpringBoot则是Spring生态的进一步封装，默认内嵌Tomcat、自动配置、简化依赖管理。在实际落地时，我直接选了SpringBoot 2.7.x，原因是它对SSM的底层能力完全兼容，却省掉了一大堆XML配置，开发效率提升非常明显。

真正需要认真决策的不是SpringBoot还是SSM，而是后端要不要独立于前端。早年的做法是后端用Thymeleaf或JSP直接渲染页面，一套SpringMVC全搞定。但放到现在，管理后台要做复杂交互（表格、弹窗、图表），学生端要跑在微信小程序里，如果还指望后端直出页面，小程序端就没法复用任何界面逻辑，等于要维护两套前端。项目一开始就确定前后端分离：后端只提供JSON接口，管理端用Vue3 + Element Plus，学生端用UniApp，三者都通过HTTP接口通信。这套架构的收益在后期非常明显——管理端加了统计报表功能，小程序端完全不受影响。

1.2 后端框架的取舍：SpringBoot + MyBatis-Plus + JWT

后端的技术栈最终锁定为 SpringBoot + MyBatis-Plus + JWT + Redis，这个组合是许多管理类系统的默认解，但每项选型都有明确理由。

数据持久层选MyBatis-Plus而不是原生MyBatis，是因为课程管理系统的SQL大多是单表CRUD加上简单的联表查询，MyBatis-Plus的BaseMapper帮我们把insert、update、selectById、分页查询全部内置了，写代码时只需要关注业务逻辑。更关键的是它提供了逻辑删除、自动填充（create_time、update_time）、乐观锁插件，这些功能在用户管理、课程管理场景里全部用得上。

权限控制没有引入Spring Security，而是用了JWT + 拦截器。Spring Security本身很强，但它有一套完整的过滤器链和配置体系，对团队里刚接触这类项目的开发者有一定成本，而且网络课程系统的角色模型很简单，无非是管理员、讲师、学生三种。用JWT做登录态，拦截器里校验Token并解析用户角色，代码量少、逻辑直观，出了问题也容易排查。如果后面真要对接OAuth2或细粒度权限，再演进到Spring Security也不迟。

接口层面还做了统一返回体和全局异常处理。前端不管拿到成功还是失败的数据，都能从同样的结构里取值：

@Data public class Result<T> { private Integer code; // 200成功，500失败，401未登录 private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("success"); result.setData(data); return result; } }

1.3 小程序端为什么选UniApp而不是原生

学生端跑在微信小程序上，这是需求里明确写的。技术选型时列过三个选项：微信原生小程序、Taro、UniApp。微信原生的问题在于它只能服务微信一个平台，如果后续学校要求上支付宝小程序或企业微信内的H5，就得重新写一遍。Taro的生态更适合React背景的团队，而我们已经确定了Vue技术栈。

UniApp最大的优势是用一套Vue代码编译到微信小程序、H5、App等多个平台。在这个项目里，课程列表页、课程详情页、学习记录页这些核心页面，在小程序和H5端都能跑，一套代码两处复用。实际开发中发现，UniApp对Vue3的支持已经很成熟，组合式API（setup）写起来顺手，组件生命周期也基本对齐了Vue生态的习惯。

当然UniApp也有它的限制。比如微信小程序的video组件和UniApp封装的video组件，在某些基础库版本上行为不完全一致，需要真机调试去验证。再比如小程序的包体积限制，要求我们在项目里做分包加载。这些坑在后文会展开讲。

2. 数据库与接口设计：课程、选课、学习记录如何串起来

2.1 核心表结构设计

网络课程信息管理系统，表面上是"课程管理"，但真正决定系统复杂度的其实是选课关系和学习进度。课程信息本身很简单，无非是标题、封面、分类、讲师、简介；难的是要搞清楚"谁选了哪门课""学到了哪一节""视频看到第几分钟"这些状态。

核心表一共设计了七张：

设计时最大的一个判断是：把"章节"和"视频资源"拆成两张表。很多初学项目会直接在一个章节表里塞video_url字段，这对录播课来说够用，但一旦出现一个章节里有多个小节、每个小节对应一个视频的情况，父子的层级关系就很难表达。拆开后，course_section 用 parent_id 支持无限级章节结构，course_video 挂在具体小节下，后续即使要扩展资料下载、图文章节，也不用改动课程表结构。

选课记录和学习记录也做了拆表。course_enroll 关心的是一张“选课凭证”——学生有没有选这门课、整体学到了百分之多少；learn_record 关心的是细到每一节视频的观看位置。这两者的关系是一对多：一条选课记录，对应多条学习记录。每次学生暂停视频，小程序端就把观看位置上报一次，后端更新对应的learn_record，同时按已完成的章节数量重新计算course_enroll里的progress。计算逻辑用一条SQL就能完成：

UPDATE course_enroll ce SET ce.progress = ( SELECT ROUND(COUNT(DISTINCT lr.section_id) * 100.0 / (SELECT COUNT(*) FROM course_section WHERE course_id = #{courseId}), 0) FROM learn_record lr WHERE lr.user_id = #{userId} AND lr.course_id = #{courseId} AND lr.is_finish = 1 ) WHERE ce.user_id = #{userId} AND ce.course_id = #{courseId}

2.2 接口规范与统一返回

整个系统有几十个接口，如果没有统一规范，前端联调就是灾难。我们在一开始就定了几条硬规矩。

接口路径按资源命名，管理端接口以/admin开头，小程序端接口以/app开头，例如/admin/course/page、/app/course/list、/app/learn/report。这样做的好处是Nginx反向代理时可以直接按前缀分流，后端拦截器也能精确区分哪些接口需要管理员权限、哪些只需要登录。

分页参数统一为 pageNum 和 pageSize，返回结构统一为{ records, total, pages }。所有时间字段统一返回时间戳，前端按需格式化，避免后端时区问题和日期格式不一致的争论。

课程列表接口的返回中，我额外加了一个alreadyEnroll字段，这个字段由后端根据当前登录用户的选课记录动态计算。前端拿到这个字段后，课程卡片上直接显示"选课学习"或"继续学习"，不用额外调一次查询选课状态的接口，对小程序端的性能很友好。

2.3 权限控制的处理思路

权限控制分了两个层面：接口层面的登录校验，以及数据层面的角色权限。

登录成功后，后端签发JWT，将 userId 和 role 放入token，有效期设为7天。小程序端把token存在storage里，每次请求由uni.request拦截器自动携带到Header的 Authorization 字段。后端有一个前置拦截器，先放行登录接口和课程公开接口，其余请求统一校验token。解析出角色后，把用户信息放入ThreadLocal，后续业务代码可以直接取当前操作人。

管理端接口会额外校验角色，比如删除课程接口要求role等于0（管理员）。我的做法是写了一个@RequireRole("admin")注解加在Controller方法上，拦截器里通过反射读取注解并比较角色，实现起来非常简单，却能把权限逻辑从业务代码里剥离开。

数据层面还有一层"讲师只能管理自己的课程"的约束。讲师登录后创建查询条件时，后端会从ThreadLocal里拿到当前用户的id，强制拼上teacher_id = 当前用户id，这样讲师调接口时看不到别人名下的课程数据。这类行级权限在后续做数据隔离时非常管用。

3. 管理端实现：课程编排、用户管理、权限控制的落地细节

3.1 课程管理中的富文本与视频上传

管理端本质上是给管理员和讲师维护业务数据的工具，界面不需要花哨，但交互要稳。课程管理页面拆成两个部分：课程列表和课程详情。

课程列表是一个典型的分页表格，Element Plus的 el-table 加上 el-pagination 就能满足。真正麻烦的是课程详情编辑，因为课程简介需要支持富文本，视频上传需要支持大文件。富文本我用的 wangEditor（Vue3版本），它比TinyMCE接入方便，中文文档全，而且按需引入了图片上传功能。注意，富文本里的图片上传要单独写一个接口，接收FormData文件后返回图片访问URL，编辑器再用URL回填。

视频上传走的是分片上传方案。普通上传在视频文件超过200MB时很容易超时，分片上传把大文件切成5MB一块，前端用并发请求把分片上传到后端，后端每收一片就记录进度，全部传完后调用合并接口，由后端把分片合并成完整视频文件。我封装了一个通用上传组件，核心逻辑用UniApp的uni.uploadFile或Axios都能实现，但进度条、暂停续传、断点重试这些细节比较花费时间。项目初期如果不想给自己挖坑，先限制单个视频不超过500MB，用普通上传加上Nginx的超时时间调大，也能撑住大部分录播课的使用场景。

3.2 用户管理与角色划分

用户表里通过role字段区分管理员、讲师、学生，管理端的不同角色登录后看到的菜单不同。菜单权限在Vue端用路由守卫实现：后端在登录接口里返回当前用户的角色和权限标识，前端router.beforeEach里判断目标路由需要的权限，没有权限就重定向到403页面。

用户管理页面做三件事：列表查询、新增用户、禁用用户。新增用户时后端对密码做BCrypt加密存储，不能明文落库。禁用用户最常用的方式不是删记录，而是把status字段改为1，同时后端在JWT校验时判断用户状态，被禁用的用户即使token还没过期，也会在请求时被拦截。这个细节如果漏掉，用户被禁用后还能继续访问接口，是非常严重的漏洞。

管理员给讲师分配课程时，可以做成在讲师列表页点击"分配课程"，弹窗里勾选课程。这个功能在后端只需要维护 course 表的 teacher_id 字段，不需要额外建关联表，因为一门课只有一个主讲讲师。如果以后需求变成"多个讲师共同负责一门课"，就要加一个 course_teacher_relation 表，但现阶段不需要过度设计。

3.3 数据统计模块的简单落地

网络课程管理系统里，学校很希望看到"哪些课是热门课""学生的整体学习进度如何"。这类统计需求不复杂，SQL里加上GROUP BY就能完成。

首页统计面板展示四组数字：课程总数、学生人数、今日新增选课、视频总时长。今日新增选课这条SQL有个常见坑，就是对create_time字段用了函数计算后再比较，导致索引失效。正确写法是 create_time >= 当天零点 这个范围条件。

课程热度排行、选课趋势图用了ECharts。ECharts的Vue3封装包虽然方便，但它对包体积不友好，小程序端又不依赖它，所以我把统计功能单独放在一个页面，使用动态import加载，避免管理端首屏加载变慢。

4. 小程序端与数据联动：登录态、学习进度、视频播放的坑与解法

4.1 uni-app 的项目结构与跨端思维

学生端是基于uni-app创建的Vue3项目。整个项目的目录结构是标准的分页模式：pages目录放主包页面，subpkg目录放分包页面。主包只放首页、课程列表、我的三个核心Tab页面，课程详情、视频播放、选课记录这些页面全部放到分包里，解决了微信小程序的包体积限制。

pages.json里的配置决定了TabBar和页面路由，官方文档写得很清楚。这里最想提醒的是，不要在小程序页面里直接写样式覆盖全局变量之外的东西。因为UniApp编译到小程序后，CSS的优先级和H5不完全一致，某些全局样式很可能会被页面样式意外覆盖。处理办法是定义一套统一的scss变量和通用类，页面上只写业务独有的样式。

开发时务必使用条件编译注释，比如// #ifdef MP-WEIXIN和// #ifndef MP-WEIXIN。我遇到过H5端正常、小程序端白屏的问题，原因就是某段代码里用了浏览器专属的window对象。在UniApp里判断平台不是用typeof window去猜，而是用uni提供的条件编译。

4.2 登录态怎么和小程序生态打通

小程序登录流程和Web登录完全不同。Web登录通常是用户输入账号密码，后端验证后发token。小程序最常用的是微信授权登录：前端调用 wx.login 拿到临时code，把code发给后端，后端再调用微信接口换取openid，用openid去查用户表，如果不存在就自动注册，最后签发JWT返回给前端。

自动注册的逻辑需要注意，新用户直接给默认昵称"微信用户"，头像给默认头像URL。我第一次做这个流程时踩了坑——只保存了openid，没做unionid的兼容。结果同一用户在不同小程序里openid不同，虽然当前系统影响不大，但如果后续要做跨端账号合并，就得提前把unionid字段留出来。

登录成功后的token存储和请求拦截是重点。我在uni-app里封装了一个 request 工具函数，核心逻辑是：

const request = (options) => { return new Promise((resolve, reject) => { const token = uni.getStorageSync('token') uni.request({ url: baseUrl + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'Authorization': token ? `Bearer ${token}` : '' }, success: (res) => { if (res.data.code === 401) { uni.navigateTo({ url: '/pages/login/login' }) reject(new Error('未登录')) } else { resolve(res.data) } }, fail: reject }) }) }

所有接口都走这个封装，遇到401直接跳登录页，业务代码里不用重复写登录失效的判断。

4.3 视频播放与学习进度上报

视频播放是最核心的功能。课程详情页里，非选课用户能看到课程的基本信息和章节列表，但点击视频时会弹出选课提示；选课用户点击任一章节，跳转到播放页并带上当前章节的sectionId和videoId。

播放页用video组件，src直接绑定video_url。视频播放过程中，通过bindtimeupdate事件获取当前播放时间。上报策略不能太频繁，每15秒上报一次，或者当播放位置跨越整分钟时上报，这样可以减少后端压力。我采用的方法是：在timeupdate回调里判断，如果距离上次上报超过15秒就触发上报，上报内容是当前videoId和播放位置。

一个容易忽略的问题是视频播放过程中的进度恢复。用户上次看到3分20秒退出，下次进入这个视频应自动跳转到3分20秒。实现方式是课程详情页加载时，调一个接口查询该用户在当前章节的学习记录，拿到watch_position后传给video组件的initial-time属性。这个体验细节对学习类小程序很重要，直接决定用户愿不愿意继续用。

再有一个隐蔽的坑：微信小程序的video组件在某些安卓机型上，播放到一半可能触发error事件，表现为黑屏或卡死。排查后发现是视频编码格式的问题，部分视频是H.265编码，小程序端兼容性不好。统一转成H.264编码、音频编码为AAC、使用MP4格式后，问题基本消失。

4.4 选课逻辑与课程评论

选课功能是学生端和管理端数据联动的关键。课程详情页底部有一个"立即选课"按钮，点击后调/app/course/enroll接口，后端先在course_enroll表里查重，如果已经存在就直接返回"已选课"，否则新增一条选课记录。这个查重逻辑一定要放在事务里，否则同一用户并发点击两次会插入两条记录。MySQL的InnoDB在默认隔离级别下，先查再插存在并发间隙锁的问题，最稳妥的方案是在course_enroll表上加唯一索引(user_id, course_id)，配合事务保证幂等。

课程评论功能允许选课用户对课程打分、写文字评价。评论表我放在单独表course_comment里，没有和learn_record混在一起，因为两者的访问模式不一样：评论是高频读取的展示数据，学习记录是高频写入的行为数据，混一起会让SQL变得不清晰。

接口返回评论时做了两层处理。第一层只返回通过审核的评论，第二层按时间倒序分页。管理员可以在管理端看到所有评论，包括未审核的，这条链路过早不设计好，后期补审核功能要改动多处SQL。

5. 部署上线与性能调优：从本地调试到服务器稳定运行

5.1 本地联调阶段容易踩的坑

本地开发阶段，管理端用Vite启动在localhost:5173，后端跑在localhost:8080，小程序端在微信开发者工具里调试。三个端同时开发，最常遇到的就是跨域问题。

Vite的跨域处理很简单，在 vite.config.js 里配置server.proxy，把 /admin 和 /app 开头的请求都代理到 http://localhost:8080。注意代理要同时处理WebSocket的ws:true选项。

小程序端的跨域策略不一样。微信开发者工具可以勾选"不校验合法域名"，但如果要在真机上调试，就必须把后端地址配成HTTPS域名，而且要在微信公众平台后台配置request合法域名。本地联调时，我通常在小程序端把baseUrl指向一个内网穿透地址，或者干脆连同一个局域网内后端的IP地址。

5.2 Nginx + 云服务器部署流程

部署阶段不复杂，但有几个必须注意的环节。

后端打包用maven，执行mvn clean package -DskipTests生成jar包，上传到服务器后使用nohup启动：

nohup java -jar course-system.jar --spring.profiles.active=prod > log.out 2>&1 &

服务器上我用Nginx同时承担两件事：托管管理端的静态文件，反向代理后端的API请求。前端构建产物是dist目录，直接上传到/usr/share/nginx/html/admin下。Nginx配置如下：

server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/admin; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /file/ { alias /data/course-files/; } }

这段配置里有两个关键点。try_files是为了Vue路由的history模式，前端路由刷新时不会404。location /api/后面的proxy_pass 末尾带了一个斜杠，它会把/api/course/page重写为后端/course/page，后端Controller里不需要再加 /api 前缀，接口路径保持整洁。

视频文件和图片统一放在服务器的/data/course-files目录下，且通过Nginx的 /file 路径直接访问，不走Java进程。这样做避免了Tomcat对上传文件的限制，也减轻了Java进程的I/O压力。

如果小程序要求HTTPS，需要申请SSL证书，然后修改Nginx配置增加443端口和证书路径。这个流程在各大云厂商都有文档，但有一个坑：证书更新后Nginx不会自动重载，需要手动执行nginx -s reload，否则到期后小程序端会无法访问。

5.3 性能优化三板斧：索引、缓存、分页

系统上线后，随着学生人数和课程数量增加，数据库查询压力会出现。这个项目做好三件事就能扛住大部分场景。

第一是索引。课程列表页按分类和时间排序，所以course表的category_id、create_time字段要建索引。learn_record表查询最频繁的条件是(user_id, course_id)，所以建联合索引。course_enroll表的唯一索引已经在前面提到过，既能保证幂等，也能加速查询。用EXPLAIN查看执行计划，如果出现Using filesort，就要检查排序字段是否在索引中。

第二是缓存。课程详情页是访问最密集的接口，而且课程内容变化频率很低，非常适合用Redis做缓存。缓存的key设计为course:detail:{id}，查询时先读缓存，缓存没有再去查库并把结果写回Redis，同时设置过期时间30分钟。这样即便同一门课被1000个学生同时点开，后端也只需要查一次数据库。

第三是分页深度问题。后台管理端的课程列表翻页到几百页时，LIMIT 10000, 20这种深分页查询会变慢。解决办法是使用游标分页：WHERE id > 上次最大id ORDER BY id LIMIT 20，而不是传统的limit offset。管理端场景完全可以用这种方案。小程序端的课程列表也建议这么做，但封面图、简介等字段不多，传统分页配合索引也能接受。

还有一个优化点容易被忽略：静态资源加缓存头。Nginx配置里给 /file 路径下的视频、图片、字体设置expires 7d，用户重复请求同一资源时直接命中浏览器缓存，视频播放的启动速度会有明显改善。

5.4 上线初期遇到的两个实际问题

第一个问题是上传的视频无法播放。排查后发现不是代码问题，而是avi和mkv格式的封装只适合本地播放，Web和小程序端对容器格式支持有限。后来我在项目说明里明确要求讲师上传MP4格式，并写了一键转换脚本，批量把存量视频转码。

第二个问题是文件存储目录权限。后端上传文件时用的相对路径，本地正常运行，部署到服务器后发现上传失败，排查日志才明白是当前运行jar包的目录不可写。调整为绝对路径/data/course-files并给目录设置755权限后解决。

这两个问题都不是复杂的技术难题，但都属于"本地不会暴露、一部署就出事"的经典坑，提前在部署文档里写清楚，能省掉不少排查时间。

写在最后的一点体会

这套基于SpringBoot + Vue3 + UniApp的网络课程信息管理系统，从需求调研到上线运行，前后花了将近一个月。最深的感受是：这类系统的技术选型并不是越新越好，而是要在团队熟悉度、业务复杂度、后期维护成本之间找平衡。SpringBoot + MyBatis-Plus + Vue3 + UniApp这套组合，单看每个技术都是社区成熟方案，拼在一起却能覆盖"管理后台 + 学生小程序"的完整业务闭环。

如果后续要扩展，我建议往这两个方向考虑：一是增加在线支付购买课程，需要对接微信支付并处理好回调通知的幂等；二是引入消息推送，把课程更新通知、评论回复通知推送到小程序订阅消息里。这两个功能都会让系统的商业价值更完整，但也会引入新的复杂度，到时候需要在架构上再做一轮权衡。

最后再分享一个小经验：开发这种多端项目，前后端联调的接口文档一定要在开工之前列出来，字段名、状态码、分页格式先达成一致，比写完再对着改效率高太多。项目里所有踩坑和优化细节，都在部署视频和源码注释里做了详细标注，照着流程走一遍，基本不会卡住。