SpringBoot2+Vue3+MyBatis-Plus在线课程管理系统项目完整解析

1. 项目概览与技术定位

做Java Web开发的朋友，应该没有谁没碰过“课程管理系统”这类题目。从学校里的课设、毕业设计，到公司里的内部培训平台、在线教育项目的前身，这套业务几乎是Java后端开发者绕不开的练手场景。而今天我打算认真说说的，是一个基于SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0的在线课程管理系统完整源码项目。

先说这套东西能干什么。它不是一个只有增删改查的“空壳管理端”，而是一个面向真实教学场景的在线课程管理平台——里面有用户登录认证、角色权限控制、课程信息管理、课程章节内容维护、学生选课退课、学习进度记录、后台数据统计这些核心闭环。前端用Vue3做单页应用，后端用SpringBoot2提供RESTful接口，数据库端用MySQL8.0做持久化存储，ORM层用MyBatis-Plus来简化数据访问。整个项目前后端分离，代码结构清晰，附带完整的项目文档和数据库初始化脚本，无论是拿来作为毕业设计、课程设计的基座，还是想通过一个完整项目学习主流Java全栈技术，都很合适。

在正式开讲技术细节之前，我想先给这个项目一个定位：它既不是一个纯Demo级别的教学示例，也不是一个商业级的重量级平台，而是一个“中间状态”的完整系统。说得更直白一点，它正好踩在“能学到东西”和“能跑起来交差”的最佳平衡点上。技术栈选得保守但不落后，业务模型覆盖了主流在线教育场景的核心表结构，代码组织上遵循了企业开发的分层规范。这种项目有一个很大的好处——你既能把它当作学习的靶子，一行一行读懂每个技术点的落地方式；也能直接在上面做二次开发，换皮、加功能、改业务流程，去满足毕业设计或者实际工作中的定制需求。

这个项目适合谁来参考？我认为有三类人最合适。第一类是准备做毕业设计或课程设计的在校生，需要一个结构完整、文档齐全、技术栈具备一定时代感的系统来作为起点；第二类是正在学习SpringBoot + Vue全栈开发、但苦于没有完整项目练手的自学者，这个项目提供了从数据库设计到前端页面的一整条串联链路；第三类是初级开发人员，想看看在一个中等规模的管理系统中，MyBatis-Plus怎么设计查询、Vue3怎么组织权限路由、SpringBoot的安全框架怎么集成——这种“成套”的经验在零散教程里比较难一次集齐。

下面我会从数据库设计、后端编码、前端实现、环境部署、问题排查这几个维度，把我在看源码、复现运行、二次改造过程中积累的经验完整写出来。尤其是那些网上教程不常讲的细节，比如MySQL8.0连接串里的时区参数、MyBatis-Plus分页插件必须手动注册的坑、Vue3路由守卫与本地缓存的同步问题，我都会逐个说明。

2. 系统核心业务与功能模块拆解

2.1 用户角色与权限体系的落地思路

在线课程管理系统做得像不像样，第一个看点就是权限模型清不清楚。这套系统的用户角色划分得很常规，但也很实用：系统管理员、教师、学生。管理员负责整体后台配置，比如用户管理、课程审核、公告发布；教师负责创建课程、维护章节、管理自己课程下的学生；学生则浏览课程、选课、学习、查看进度。

从技术实现上看，权限这块走的是现在Java Web项目里最常见的JWT + 拦截器/过滤器方案，而不是那种重型的Shiro或Spring Security全量配置。登录成功之后后端签发一个Token，前端拿到Token存储在本地，每次请求在请求头里带上，后端通过拦截器校验Token并解析出当前用户身份和角色。这种方案在前后端分离场景下实现简单、扩展方便，对于这个规模的项目来说完全够用。

我仔细阅读源码后发现，后端权限控制做得比较聪明的地方在于它并没有在每个Controller方法里写死角色判断，而是用了一个自定义注解结合拦截器的方式——在需要特定角色才能访问的接口上标注注解，拦截器统一处理。这样代码侵入性很低，业务代码保持干净。你要是想改造这个项目，把管理员接口、教师接口、学生接口分开管理，核心逻辑也不需要大改。

2.2 课程从创建到学习完成的闭环设计

来看看业务层面。在线课程管理，核心链路就是“教师创建课程 → 维护章节内容 → 学生浏览选课 → 在线学习 → 记录进度”。这套系统把整条链路的数据模型和接口都打通了。

先说课程管理。教师登录后可以创建课程，填写课程名称、简介、封面图、分类、难度等级，还可以设置课程状态（草稿、已发布、已下架）。一旦课程发布，学生就能在课程大厅看到。这个流程对应后端至少两张核心表：课程表和课程分类表，加上用户表，构成最基础的关系。

课程章节设计是在线课程的灵魂。这套系统中一个课程下面挂多个章节，章节包含标题、排序、视频URL或富文本内容、时长等信息。这里我重点说下视频资源这块的设计，它复用了本地上传或者对象存储返回的URL，数据库里只存地址不存二进制文件。这个决策是非常理性的——视频文件体积大，如果直接存数据库，备份和迁移都会变成噩梦。

学生端的学习闭环是另一个值得讲的模块。学生登录后可以浏览课程列表，查看课程详情，选择课程后进入“我的课程”。后端记录选课关系，并初始化学习进度。学生学习某个章节时，前端上报学习事件，后端更新该学生在当前课程下的最后学习章节和进度百分比。这样一来，“继续学习”这种看似简单的功能，底层需要的表结构和接口设计就全都有了。

2.3 后台数据看板与统计模块的设计价值

很多类似的课程管理系统项目只把重点放在CRUD上，统计数据这块往往做得非常简陋甚至完全没有。而这个项目的完整度在数据统计上体现得很明显——它提供了一个后台数据看板，能够展示核心指标：用户总数、教师数量、学生数量、课程总量、选课总人次、最新注册用户列表等等。

从数据层面上看，这些统计并不复杂，就是几个带条件的count查询和最近的记录查询。但从产品价值上看，它把系统从“能用”拉到了“像一个真正的系统”的高度。一个做课设或毕设的项目，如果有这样一个数据看板放在首页，答辩时给老师的观感会截然不同——它说明了你不只是会堆CRUD，而是从产品的角度考虑了管理员的日常工作需求。

同时，这里的统计查询也给了MyBatis-Plus展示聚合能力的好机会。比如统计每个分类下的课程数量，这种分组聚合查询在MP里可以直接结合QueryWrapper的select和groupBy方法去实现。我看源码时注意到这里用MP的selectMaps方法接收返回结果，这种方式能够天然适配不确定类型的Map返回结构，不用为了统计单独写一堆VO类，很实用。

3. SpringBoot2 + MyBatis-Plus + MySQL8.0后端实现要点

3.1 为什么选SpringBoot2而不是SpringBoot3

技术选型永远是项目落地时回避不了的问题。近两年SpringBoot3已经发布了，很多人一上来就问：为什么不用3.x？我在实际复盘这套源码的时候，认为选SpringBoot2是非常务实的选择。

核心原因在于生态兼容性。MySQL8.0连接驱动、MyBatis-Plus、JWT库、各类文档生成工具，这些在SpringBoot2.x版本下都有经过大量生产验证的组合方案。而SpringBoot3从Jakarta EE的包名迁移到Spring Framework 6底层，很多老版本的第三方库如果没有及时适配，就会出现包名冲突、方法过时甚至直接启动失败。对于需要快速交付课程设计或者毕业设计的场景，与其在版本适配的坑里浪费大量时间，不如选一条成熟稳定的路。

SpringBoot2.x虽然不算最新，但绝对不算老旧。它依然占据着大量企业生产环境，相关的踩坑资料、问答方案在网上也是最丰富的。真遇到问题，一搜就能找到答案，这一点对于经验尚浅的开发者来说格外重要。说到底，在线课程管理系统这种业务，核心难点从来不是“用上最新框架”，而是“把业务模型设计清楚、把数据链路跑通”。

3.2 项目分层结构与代码组织方式

拿到源码后，我建议你先别急着跑，先把整体代码结构浏览一遍。这套项目的后端分层很标准，就是常见的四层结构：

• Controller层：负责接收HTTP请求、参数校验、调用Service层、返回统一结果。
• Service层：负责业务逻辑处理，事务控制。
• Mapper层：继承MyBatis-Plus的BaseMapper，获得通用CRUD能力。
• Entity实体层：与数据库表的映射对象。

另外还有一个很关键的config包，配置类都放在这里，包括MyBatis-Plus分页插件配置、跨域配置、JWT拦截器注册等。还有一个common包，放统一返回结果类、异常处理类、工具类。对于想学项目结构的开发者来说，这套分包方式本身就是极好的参考模板——每个类该放在哪里、职责边界在哪，一目了然。

Controller层在设计上有个不错的习惯：接口返回类型统一封装为一个Result对象，里面包含状态码、消息、数据三个字段。前端只需要在请求拦截器里统一处理这个对象，判断状态码、弹出错误消息、解包数据，而不需要每个接口单独处理异常，大幅降低了前后端联调成本。我看过太多课程设计项目，返回格式五花八门，有直接返回Map的，有返回字符串拼接JSON的，还有返回裸数据的，这给前端造成了极大的麻烦。统一封装返回体这件事，希望每个正在做全栈项目的人都养成习惯。

3.3 MyBatis-Plus的核心实践与踩坑记录

MyBatis-Plus这个ORM增强框架，现在基本是Java Web项目的“标配”。它最核心的价值在于继承了BaseMapper之后，单表的CRUD完全不用手写SQL，大幅减少样板代码。这个项目里大量使用了MP的QueryWrapper和LambdaQueryWrapper构建查询条件，代码写起来很流畅。

我在源码中特别关注了几个MP高频特性的使用方式，这里整理一下：

逻辑删除是通过在实体字段上加@TableLogic注解实现的。这个项目在用户表、课程表的删除操作上采用了逻辑删除策略。逻辑删除的底层原理是：MP在生成通用SQL时自动追加“deleted = 0”条件，执行删除时自动改成“deleted = 1”的更新语句。这样做的好处是历史数据不会真正消失，对以后的数据分析、报表统计都有价值。对应的代价是，你在写统计SQL时要注意过滤掉已删除的数据，避免数据错乱。

自动填充是MP另一个好用的功能。比如创建时间、更新时间这两个字段，如果每次插入和更新都手动set，不但代码冗余，还容易遗漏。MP的MetaObjectHandler接口允许你定义一个handler，在insert或update操作时自动填充指定字段。这个项目里的公共字段处理就是走的这个方案。

分页这块我要多说两句——因为踩坑概率实在太高。MP的分页功能默认是不生效的，你必须在配置类里注册一个PaginationInnerInterceptor，否则Page对象返回的数据会是全量而分页信息丢失。这个项目在MybatisPlusConfig里正确配置了分页插件，这也是我在看代码时特意确认过的点。分页插件同时需要指定数据库类型，代码里用的是DbType.MYSQL。如果你在整合MP到自己的项目时发现分页不生效，不用多想，十有八九是漏了这一步配置。

3.4 多表关联查询的务实处理方式

做课程管理系统，不可能只有单表操作。比如课程列表要显示教师的昵称、分类的名称，这就需要联表查询。MyBatis-Plus的BaseMapper只解决单表CRUD，多表关联怎么办？这套项目给出的答案是：在Mapper层自定义方法+XML文件编写SQL。

具体来说，先定义一个扩展的Mapper接口方法，比如selectCourseDetailList，然后在resources目录下的Mapper XML文件中编写联表查询SQL，通过resultMap或直接映射到自定义VO对象返回。这其实是MP体系中非常标准的操作方案——MP负责解决80%的单表重复劳动，而复杂的多表查询依然保留MyBatis注解或XML的自定义能力。

这里我要推荐一个我在实践检验中觉得最顺手的实现方式：自定义VO类 + XML中的resultMap完成映射。不去用MyBatis的自动驼峰映射到实体，因为多表查询返回的字段经常来自不同表的组合，甚至包含聚合计算结果（比如课程下的章节数量），用一个明确的VO类去接收，语义清晰，可维护性也高。有些开发者习惯把多表查询结果塞进Map里，短期看是快，但后期维护时根本不知道Map里的key对应什么含义，非常痛苦。

联表查询的SQL本身不建议写得过于复杂，尽量把复杂查询拆解成多次简单查询再在Service层做数据组装。这种做法在数据量不大时性能没有问题，还能减少SQL编写出错率，提高代码可读性。

4. MySQL8.0数据库设计与关键配置

4.1 数据库表结构设计的核心思路

看一个管理系统项目的含金量，打开数据库脚本文件扫一眼表结构，心里基本就有数了。这套在线课程管理系统的数据库脚本做得很规整，表结构覆盖了核心业务链路的每一环。

用户表应该是整个系统的地基。基本信息、用户名、加密密码、真实姓名、邮箱、手机号、头像、角色类型、创建时间、更新时间、逻辑删除标记。密码加密不使用MD5这种不可逆但已不安全的算法，而是采用BCrypt加密，这一点代码里体现得很清楚。

课程表的设计包含标题、封面、分类ID、教师ID、简介、难度、价格（如果涉及付费场景）或直接免费、状态、创建时间、逻辑删除等字段。其中教师ID作为外键关联用户表，分类ID关联分类表，这种设计让课程维度的信息查询变得很顺手。

课程章节表承载了教学内容的组织。课程ID、章节标题、章节排序、视频URL、内容正文、预计学习时长。如果还包含课时或小节的概念，可以再加一层。这套系统的章节设计相对扁平合理，一个课程下直接挂章节，没有过多嵌套，对于中小规模在线教学场景已经足够清晰。

选课表是连接学生和课程的枢纽。它记录了哪个学生选了哪门课程，选课时间，学习进度（百分比），最后学习的章节ID。因为有这张表的存在，“我的课程进度”这类功能才具备实现基础。设计时要注意给“用户ID + 课程ID”建立唯一索引，防止学生重复选课。

4.2 MySQL8.0连接配置中的那些隐藏细节

很多人在配置MySQL8.0连接时会遇到各种莫名其妙的问题：连不上、中文乱码、时间差了8小时、驱动类找不到。这些问题基本都能在连接串上找到答案。

先看驱动类名。MySQL 8.x对应的驱动类不再是com.mysql.jdbc.Driver，而是com.mysql.cj.jdbc.Driver。SpringBoot2的默认数据源配置会使用这个驱动，但如果你是完全手写配置，需要特别注意类名差异。

再看连接串。MySQL8.0版本对时区处理变得敏感，建议在连接串中显式指定时区参数，避免服务器与数据库所在时区不一致导致的时间偏移问题。比较稳妥的在application.yml中的配置方式是这样的：

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/course_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: 你的密码

这里有几个容易被忽略但是至关重要的参数我需要单独解释。

useSSL=false是因为本地开发环境没有配置SSL证书，默认开启SSL会让MySQL连接发出警告甚至连接失败。serverTimezone=Asia/Shanghai指定代码运行时的时区行为，如果不配置一些地区会报“The server time zone value”的异常。allowPublicKeyRetrieval=true这个参数是在MySQL8.0使用caching_sha2_password认证插件时经常会用到的配置，如果连不上数据库报错提示public key retrieval is not allowed，加这个参数就能解决。

字符编码层面，除了连接串指定UTF-8，建库时也建议显式指定：

sql复制CREATE DATABASE IF NOT EXISTS course_system 
DEFAULT CHARACTER SET utf8mb4 
COLLATE utf8mb4_general_ci;

这里选择utf8mb4而不是utf8，原因在于utf8在MySQL中最多只支持3个字节的字符，像emoji这类4字节字符无法存储，而utf8mb4是完整的UTF-8实现。既然已经用了MySQL8.0，直接上utf8mb4是最省心的选择。

4.3 MySQL8.0严格模式与分组查询的兼容技巧

MySQL8.0默认开启了严格SQL模式（STRICT_TRANS_TABLES等），它的直接影响是：插入或更新数据时，如果字段值不符合约束（比如超长、类型不符），不再像5.x版本那样自动截断并给警告，而是直接报错。这个特性对开发阶段其实是好事，能尽早暴露数据问题。

在做统计类查询时，MySQL8.0的ONLY_FULL_GROUP_BY模式值得单独拎出来说。这个模式要求SELECT列表中的非聚合列必须出现在GROUP BY子句中。比如你想统计每个分类下有多少门课程，如果查询里只select了分类名和count(*)，那没问题；但如果把课程标题也select出来而不加进GROUP BY，就会报错。

我在这个系统的统计模块中看到，分组查询写得非常克制，需要展示的字段都用聚合函数或明确加入GROUP BY。如果你在自己扩展统计功能时遇到了“which isn't in GROUP BY”相关的报错，检查思路很清晰——看看SELECT字段是不是都需要分组，或者把不需要的字段去掉，或者改用子查询来规避。

5. Vue3前端工程化实现解析

5.1 Vite构建与工程目录的组织逻辑

前端部分使用Vue3 + Vite + Element Plus + Pinia + Vue Router + Axios这套技术组合。在当前时间点来看，这套组合几乎就是Vue3后台管理系统的“黄金标准”。

用Vite而不是Webpack做构建工具，最大的体感优势就一个字：快。开发环境启动时Vite基于原生ES Module按需编译，不用像Webpack那样做完整个项目的打包才启动服务，开发体验好了不止一个档次。对于课程管理系统这种规模的前端项目，Vite的热更新基本是毫秒级响应。

前端工程没有用复杂的高低阶目录分层，而是按照“路由视图 + 通用组件 + API模块 + 状态管理 + 工具函数”来组织。这种组织方式简洁清晰，特别适合中小型系统。我看过很多前端初学者把Vue项目目录建得相当复杂，什么layouts、components、composables、directives、filters、plugins一层套一层，结果一个总共10来个页面的系统搞出了30多个目录，反而增加了不必要的认知负担。目录结构的复杂度应该跟着项目规模走，这个项目的分层是恰到好处的示范。

5.2 组合式API的实际应用——Vue3的核心变化

有人说Vue3相比Vue2最大的变化是Composition API，这句话只说对了一半。更准确的理解是：Vue3提供了一套更灵活的逻辑复用方式。在Vue2里写功能逻辑受限于Options API，一个功能相关的代码可能被拆到data、methods、computed、watch的不同区域；而Composition API允许你按照功能维度组织代码，把相关的响应式变量、计算属性、方法、侦听器写在一起。

这套课程管理系统的前端代码在组合式API的使用上很典型。比如课程列表页的搜索筛选逻辑，使用ref定义搜索关键词、当前页、总条数，使用reactive定义列表数据和加载状态，在onMounted中拉取初始化数据，然后通过一个loadData方法把这些逻辑串在一起。整个过程代码是线性的，顺着读下来非常流畅。

这里要提一个我在Vue3开发中经常遇到的高频细节：响应式数据的解构丢失问题。很多从Vue2过来的开发者，习惯从reactive对象里解构出某个属性来用，比如const { list } = reactiveData，但解构出来的list只是一个普通变量，不再是响应式的。解决方案是从reactive对象取属性时要用toRefs()方法包裹一次，或者直接用ref定义一个独立值。项目代码里没有踩这个坑，说明作者对响应式原理掌握了基础。

computed和watch的使用在这个项目里也各有应用场景。搜索筛选在列表页通过computed实时从本地数据中过滤匹配项，处理这种轻量级的筛选逻辑是最合适的。而watch更多用在学习进度同步这类场景，当本地某个状态变化后需要通知后端保存时，用watch监听变化再触发API调用，思路清晰且不会漏掉任何一次变化。

5.3 路由守卫与权限控制的协同方案

前端路由不是简单的页面切换，需要配合后端接口的权限实现前端页面级的路由控制。这套系统的路由守卫实现方案很实用，值得细说。

项目在路由配置中将需要登录才能访问的页面添加了meta.requiresAuth标记。Vue Router的路由守卫（beforeEach）会在每次路由跳转前检查这个标记：如果当前页面需要登录，就检查本地是否存有Token，如果没有Token就跳转到登录页；如果有Token但用户信息还没拉取过，就去请求后端获取用户信息并保存到Pinia中，然后再放行。

这个方案相比动态路由（根据后端返回的菜单权限来动态生成路由表）要简单很多，对于课程管理系统这种角色类型固定的场景完全够用。动态路由适合权限粒度细、菜单随配置变化频繁的大型系统，但从实现复杂度到出错率都会高出不少。课程管理系统无非是管理员、教师、学生三种角色，只要在页面内部对不同角色显示不同入口，再配合后端接口权限拦截，数据安全就能得到保障。

路由守卫中还有一个容易踩的坑是死循环。如果你在守卫内部调用router.push或者next重定向到一个同样需要权限的页面，但是权限判断逻辑又有缺陷，就会导致不断重定向。建议在守卫里始终使用next()函数，并且设置一个“白名单”存放不需要登录的页面路径，先判断目标路由是否在白名单里，再走权限逻辑，可以规避大部分循环问题。

5.4 API请求封装与Axios拦截器设计

前端所有后端接口的请求都统一通过src/api目录下的模块导出，配合Axios实例的拦截器做统一处理。这种设计的好处是后端接口地址集中管理、请求和响应的公共逻辑（如Token注入、错误处理）只写一遍。

请求拦截器做的事情非常清晰：从本地存储或者状态管理中取出Token，把它放进请求头的Authorization字段。响应拦截器则做两件事：第一，判断HTTP状态码是不是200，如果不是就弹出统一的错误提示；第二，根据后端Result对象中的业务状态码，判断业务是否成功，如果Token过期或未授权就跳转到登录页并清理本地缓存。

封装好Axios之后，每个具体API模块函数只需返回Promise，例如课程列表接口的调用函数负责拼接URL并指定请求方式，页面里await调用后直接拿到data数据。这种分层让业务代码与网络通信解耦，后期如果后端接口地址调整，只需修改API模块中对应一行，不会影响页面逻辑。

6. 项目运行环境部署与完整启动指南

6.1 本地开发环境的版本组合建议

我在部署运行这个项目的过程中，整理了整套经过验证可行的环境组合，这里分享给大家：

后端环境的主要软件版本建议是JDK 1.8或JDK 11、Maven 3.6以上、SpringBoot 2.7.x。JDK版本在后端项目里是一个隐性约束点，如果环境里装的是JDK 17，很多SpringBoot2的老项目虽然能跑，但编译时可能出现依赖冲突问题或反射相关的报错，建议直接用JDK 8或者JDK 11，这是SpringBoot2最稳定的运行环境。

前端环境建议Node.js 14以上、npm或pnpm、Vite版本保持项目中package.json指定的版本范围即可。Node.js版本也会影响依赖安装和构建结果，如果用了太新的Node版本（比如18以上）跑老Vite项目，有时会出现OpenSSL相关的兼容性报错，这时要么升级Vite版本，要么在启动脚本里加上NODE_OPTIONS=--openssl-legacy-provider，这个环境变量处理Vite版本与Node版本不匹配时非常常见。

数据库环境使用MySQL8.0版本，可以通过直接安装本地版也可以直接用Docker方式搞定。如果你不想污染本机环境，我推荐直接在Docker里跑一个MySQL8.0实例，两分钟就能搞定：

bash复制docker run --name mysql8 \
  -e MYSQL_ROOT_PASSWORD=root123456 \
  -e MYSQL_DATABASE=course_system \
  -p 3306:3306 \
  -d mysql:8.0

容器启动后，MySQL的3306端口会直接映射到宿主机，开发环境和生产环境之间切换时只需要改连接串即可，非常方便。不过要注意容器默认存储是临时的，容器删除后数据会丢失，如果是长期项目建议给容器挂载一个日志和数据卷（volume），防止重建容器后数据被清空。

6.2 从零跑通项目的完整步骤

第一步是初始化数据库。用Navicat、DataGrip或者命令行连接到你的MySQL8.0实例，执行项目提供的course_system.sql脚本。执行完成后验证一下，看到库里出现了用户表、课程表、章节表、选课表、分类表、公告表这些表就说明脚本执行成功。

第二步是启动后端。打开application.yml，确认数据库账号密码改成你自己的，如果你用了Docker启动的MySQL，账号密码必须和docker run命令里的参数一致，不然连不上。然后在项目根目录执行mvn spring-boot:run或者在IDE里直接运行主启动类。看到类似Tomcat started on port(s): 8080的日志，说明后端启动成功。

第三步是启动前端。进入前端项目目录后先安装依赖，然后启动开发服务器。看到Vite打印出本地访问地址后用浏览器打开，能出现登录页就阶段性完成了。系统默认会提供一个管理员账号，比如admin/admin123，登录后可以验证管理员后端的核心功能是否正常工作。

6.3 后端打包与前端Nginx部署的实操配置

本地开发跑通后，如果想把这个项目部署到服务器上，需要分别处理前后端的构建产物。

后端部分，在项目根目录执行mvn clean package -DskipTests，打完包后target目录下会生成一个Jar文件。部署时直接通过java -jar方式启动，如果想让它在服务器后台持续运行，建议用nohup配合日志输出：

bash复制nohup java -jar course-system.jar > app.log 2>&1 &

前端部分，在项目目录下执行npm run build，Vite会把所有静态资源打包到dist目录。部署这些静态资源的惯用方案是通过Nginx来提供访问入口，同时还需要把接口请求反向代理到后端的SpringBoot服务。一个精简的Nginx配置片段大致长这样：

nginx复制server {
    listen       80;
    server_name  your_domain_or_ip;

    root  /opt/course-system/dist;
    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;
    }
}

那行try_files配置对Vue这种单页应用特别重要——前端路由是历史模式时，直接访问某个具体路径（比如刷新课程详情页）如果找不到对应文件，Nginx会返回404，try_files会把所有未知路径重写到index.html，由前端路由接管页面渲染。而/api/的反向代理配合后端context-path的设置，完成了前后端联调地址的统一。

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

7.1 后端启动失败问题速查

我在部署项目过程中遇到过很多次“看起来哪都对但就是起不来”的情况，这里把最常见的几类问题和排查路径整理成一张速查表：

在实际开发时可以用日志定位问题，SpringBoot启动时如果某些Bean注入失败，会把关键错误堆栈打出来。看到“Error creating bean with name”这样的字眼时，优先往数据源、Redis连接、Mapper扫描包路径这几个方向排查，绝大多数Bean创建失败都能归纳到这几类原因。

7.2 MyBatis-Plus使用中的经典坑位

第一个大坑是分页不生效。如前面提到的，必须注册PaginationInnerInterceptor，且指定数据库类型。有人会在配置类里加了@Configuration注解却被项目内的@ComponentScan覆盖掉，导致配置没有生效。排查时可以看一下Spring容器启动日志中是否加载了对应的MybatisPlusConfig类。

第二个经典坑是自动填充不执行。使用@TableField(fill = FieldFill.INSERT)注解填充创建时间时，一定要确认自定义的MetaObjectHandler类被Spring管理了。很多人把这个Handler类放在Mapper包下而没有加@Component或没有在启动类扫描范围内，导致MP在insert时找不到对应的Handler实现，字段就一直是空的。

第三个高频坑点出现在使用LambdaQueryWrapper时误用了实体属性的字符串形式。确保你调用wrapper.lambda().eq(实体类::get方法, 值)时，方法引用确实指向了实体类的Getter，如果使用了方法名拼字符串的方式拼错大小写，MP会在运行期抛出异常，这类错误不像编译期错误那么好发现，需要细心检查。

7.3 Vue3前端运行时的排查经验

前端开发人员在联调阶段最常见的报错是跨域。开发环境解决跨域有两条常规路径：一是后端配置CorsFilter允许跨域，二是前端在Vite配置文件中通过server.proxy选项把接口请求转发到后端地址。Vite代理方式更常用，因为线上Nginx配置里已经做了反向代理，开发环境与生产环境的接口地址模式越接近越好。

另一个我经常遇到的Vue3问题是：process is not defined。在Vite构建的项目中，默认不会注入process全局变量。如果项目代码或某个依赖库中引用了process.env.NODE_ENV，就会提示这个错误。解决办法有两种，一是在vite.config.js中通过define选项把process.env.NODE_ENV替换为JSON.stringify("production")，二是改用import.meta.env相关的Vite内置环境变量。

数据请求后状态不更新的问题同样是Vue3新手的高频困扰。当你调用axios获取数据后赋值给普通变量，页面却不刷新，原因八成是你用的变量不是ref或reactive定义的。Vue3只会追踪响应式数据的变化并更新视图，普通const赋值的变量在赋值后不会触发页面更新。这个坑在接手不是自己写的代码时特别容易犯，需要先检查数据定义部分再谈数据流问题。

8. 项目二次开发方向与个人实践心得

如果一个在线课程管理系统做完只交差就完事，未免有些可惜。以这套代码为基础，至少有三个方向值得花时间继续深化。

第一个方向是引入更多教学互动能力，比如给课程增加评论与问答模块、章节学习完成后的练习题、甚至组织在线的考试。数据模型上无非是增加评论表、试题表、考试记录表，接口设计思路完全延续现有模式，前端复用列表和表单的通用模式，实现起来并不复杂，但会让系统从“看视频平台”走向“教学平台”。

第二个方向是把文件资源管理做得更完善。当前视频资源走的还是URL地址形式，如果自己部署，就会面临文件要存在哪、如何防止盗链、是否做转码压缩这些问题。可以考虑接入对象存储服务，或者自建MinIO服务来管理视频和图片资源，数据库里继续存地址，但后台管理上会多出很多可控的东西。

第三个方向是数据统计维度的扩展。目前的数据看板以总量统计和简单列表为主，还可以增加折线图显示每日用户增长、课程选课趋势、不同分类课程的选课占比等图表。前端ECharts配合后端聚合查询接口，这套能力的实现会让系统在“智能化”的观感上再上一个台阶。

回顾这个系统从源码到跑通、再到我尝试二次调整的整个过程，最深的感触是：一个看似常规的管理系统，真正要让它成为“可以完整交付”的项目，涉及的细节远比表面看起来要多。数据库设计的合理性、后端接口的统一规范、前端状态的清晰管理、部署环节中每一个配置文件的正确性，这些单独拆开看似乎都不困难，但串在一起却能真正检验一个开发者对全栈工程的理解。

如果非要说一个最有价值的实操建议，我想说：拿到任何一套源码项目，都不要急着去改业务代码，先花半天时间打完整条链路——先把数据库脚本导入、再用初始账号登录后端接口、最后跑到前端页面上把核心业务走一遍，在这个过程中把工程结构、库表关系、请求链路全部梳理清楚。这套流程走完，你对整个系统的理解深度和上手速度，绝对超过直接埋头改代码的开发者。这个习惯，同样适用于未来接手任何一套遗留系统。