企业官网建设流程全解析

先说结论：这套“Java Web + 线上教育培训办公系统”源码，本质上是一个基于 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 的全栈前后端分离项目，覆盖了教育培训机构最常见的两条业务线：教学管理和内部办公。如果你正在做毕业设计、想接手一个能跑通全流程的真实项目，或者想系统看一下 SpringBoot2 + Vue3 搭配 MyBatis-Plus 的落地写法，这套源码算是一个很典型的参考样本。

文章我不打算给你复述一遍官方文档，而是想站在实际开发的角度，把这个项目从架构设计、技术选型、核心实现到部署上线，完整拆开来讲。顺便把我自己踩过的坑、排查问题的思路也一并写出来，希望能帮你省下不少瞎折腾的时间。

1. 项目整体定位与模块设计思路

先说说这个项目到底解决什么问题。线上教育培训办公系统，顾名思义，它不是单纯的“网课平台”，而是把“教学”和“办公”两条线揉在了一起。教学端面向学员和讲师，提供课程浏览、报名学习、在线视频播放、作业提交与批改；办公端面向机构内部人员，提供审批流程、公告通知、排课管理、数据统计等功能。用一套系统把对外招生和对内管理打通，是很多中小型教育机构的真实诉求。

这套源码之所以看起来“什么都有”，是因为它采用了典型的 RBAC 权限模型（Role-Based Access Control，基于角色的访问控制），把用户分成管理员、讲师、学员、教务人员等不同角色，每个角色看到的菜单和能操作的功能都不一样。这一点其实是整个系统的地基，因为教育培训场景有个很典型的特点：同一份数据，不同角色关注的角度完全不同。

举个例子，一个课程订单在学员眼里是“我的学习记录”，在讲师眼里是“我的授课班次”，在财务眼里是“营收明细”，在教务眼里是“排课占用情况”。如果没有权限和角色进行数据隔离，系统会乱成一团。所以设计上必须先确定角色边界，再围绕角色去划分功能模块，最后才是具体表结构的设计。

从学习角度来说，我更建议你把注意力放在几个核心业务闭环上，而不是一头扎进代码里试运行。第一个闭环是“课程上架 -> 学员报名 -> 订单支付 -> 课程学习”；第二个闭环是“排课申请 -> 教务审批 -> 讲师确认 -> 学员通知”；第三个闭环是“作业布置 -> 学员提交 -> 讲师批改 -> 成绩归档”。这三个闭环能跑通，整个项目的骨架也就立住了，剩下的公告、轮播图、数据报表之类的模块，更像是锦上添花。

配套文档里如果流程图和用例图画得比较清楚，建议优先看这两样，因为它们能直接告诉你系统的边界在哪里、哪些功能之间有关联、哪些其实是独立的小模块。很多初学者拿到源码第一反应是去读 Controller，但我更建议先从数据库表结构和权限表入手，搞明白“谁在什么条件下能操作什么数据”，再去看代码，角度会清晰很多。

2. 技术栈选型背后的真实逻辑

这套项目选了 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，非常符合当前国内 Java Web 项目的“主流实用组合”。下面把这几个核心技术点逐个拆开讲，顺便聊聊选型时的考量。

2.1 为什么是 SpringBoot2 而不是 SpringBoot3

SpringBoot2 目前依然是国内企业级项目里存量最大、资料最全的版本。选择 SpringBoot2 并不是因为它比 SpringBoot3 更先进，而是因为它非常稳，生态兼容性最好。尤其当你需要集成一些老牌的权限框架（比如 Spring Security 的旧配置方式），或者要用到一些针对 JDK8 优化的第三方库时，SpringBoot2 几乎是零阻力。

对于这套系统来说，SpringBoot2 承担的是标准的三层架构职责：Controller 负责接口路由，Service 负责业务逻辑，Mapper 负责数据库操作。它帮你做了大量的自动配置，比如内嵌的 Tomcat、数据源自动装配、JSON 序列化、参数校验等。你只需要关心自己的业务代码长什么样，不需要操心服务器是怎么启动的。

我见过不少初学者一上来就追新用 SpringBoot3，结果被 JDK17 的模块化限制和 Jakarta EE 命名空间迁移搞得焦头烂额。如果你只是想跑通一个完整项目，学习核心业务逻辑，SpringBoot2 绝对够用，而且你能找到的解决方案比 SpringBoot3 多一个量级。

2.2 Vue3 带来的前端开发体验变化

Vue3 相比 Vue2 最大的变化不是语法，而是设计理念。它用 Composition API 替代了原来繁琐的 Options API，让逻辑复用变得非常自然。你不需要再把代码拆散到 data、methods、watch 里来回找，而是可以根据业务功能把相关变量和函数聚在一起。

这套系统用的是 Vue3 + Element Plus 的组合，类目很典型。Element Plus 是 Vue3 生态下最常用的后台管理 UI 库，表格、表单、弹窗、分页这些后台高频组件都封装得很完善。我看网上搜索热词里有“vue3使用elementui”“vue3修改tabs标签页样式”这些词，说明很多人在实际开发中都卡在样式和组件适配这些细节上。待会我在“常见问题”部分专门把这些坑挑出来说。

Vue3 项目通常还会搭配 Vite 作为构建工具。Vite 的开发服务器启动速度比 Webpack 快一个数量级，因为它采用了原生 ES Module 按需加载，而不是把所有代码先打包再启动。如果你的电脑配置不高，这个体验差异会非常明显。

2.3 MyBatis-Plus 为什么能提升开发效率

MyBatis-Plus 不是一个新的 ORM 框架，它是 MyBatis 的增强工具，核心价值就是“只做增强不做改变”。它最大的卖点是内置了很多通用方法，比如插入、批量更新、分页查询、逻辑删除，你几乎不需要手写基础的 SQL。

举个例子，你要做一个分页查询用户列表，传统 MyBatis 需要手写 select 语句，还要单独配置分页拦截器。但在 MyBatis-Plus 里，你只要继承一个 BaseMapper，然后调用 selectPage 方法，分页逻辑就自动完成了。再配合 LambdaQueryWrapper，你可以用类似lambdaQuery().eq(User::getRole, "teacher").like(User::getName, "张")这样的链式写法构造查询条件，代码可读性比拼接 SQL 字符串强太多。

项目里用它处理课程、订单、用户这些高频 CRUD 场景，代码量会大幅缩减。不过有一点需要注意，MyBatis-Plus 虽然方便，但不要过度依赖，遇到复杂的多表关联查询、复杂的统计报表，还是要老老实实写 XML 里的自定义 SQL。这个项目里应该也是两种方式混合的，这是很合理的取舍。

2.4 MySQL8.0 到底“新”在哪里

很多教程还在用 MySQL5.7，但真实企业环境已经在逐步向 MySQL8.0 迁移了。MySQL8.0 相比 5.7 有几个非常实际的变化。

第一是默认字符集变成了 utf8mb4，可以完整存储 emoji 表情和不常见的生僻字。这在教育培训系统里特别重要，因为学员姓名、课程评论里出现特殊符号太常见了，如果是老版本的 utf8 字符集，很容易出现插入报错或乱码。

第二是窗口函数的支持。你可以用 row_number()、rank() 等函数直接在 SQL 层完成排名、环比计算，而不需要把数据拉回 Java 里做二次处理。比如统计“本月报名人数对比上月增长情况”，一条窗口函数就能搞定。

第三是性能上的改进，特别是对多核 CPU 的利用和锁机制的优化。当然，MySQL8.0 对服务器内存和磁盘的要求也更高，部署在低配服务器上时要特别留意配置参数，别上来就用默认配置，后面部署章节我会给一个参考的 my.cnf 配置。

3. 目录结构与数据表设计的正确打开方式

拿到源码后，第一步不是按 F5 运行，而是先看目录结构。前后端分离项目的目录结构是有约定俗成之感的，你只要掌握几个关键位置，后面看代码会轻松很多。下面把前后端的标准目录布局和我自己的使用习惯写出来，可以对照着源码看。

3.1 后端目录结构与分层约定

后端大概率是 Maven 标准结构，主代码放在 src/main/java 下，按照 com.xxx.system 之类的包名继续拆分。常见的分层方式是 controller、service、mapper、entity、dto、vo、config、common 这几个包。

• controller：只做参数接收和结果返回，不写业务逻辑。凡是看到 controller 里一大段 if else 的，都属于代码坏味道。
• service：业务逻辑的核心层，事务注解 @Transactional 基本都出现在这一层。比如“学员报名课程”这个动作，既要在订单表插记录，又要扣减课程库存，还要给学员生成学习记录，这三步必须在一个事务里，任何一步失败都要整体回滚。
• mapper：继承 MyBatis-Plus 的 BaseMapper，复杂的 SQL 放到 XML 文件里，利用 resultMap 做映射。
• dto/vo：这俩很容易混。dto（Data Transfer Object）是接收前端传过来的参数用的，比如注册表单、分页查询条件；vo（View Object）是返回给前端展示用的，比如订单详情、课程统计信息。把参数对象和返回对象分开，能避免字段交叉污染，尤其是密码这类敏感字段，坚决不能进 vo。
• config：存放配置类，比如跨域配置、拦截器配置、MyBatis-Plus 分页插件配置、Swagger 配置等。
• common：通用返回对象 R、全局异常处理器、工具类、常量类。看到统一封装返回对象，说明这个项目在接口规范上是花了心思的。

3.2 前端目录结构与开发调试思路

前端大概率是基于 Vue3 + Vite 的项目，src 下会有 api、views、components、router、store、utils 这几个经典目录。api 目录里一个 JS 文件对应一个业务模块的所有接口请求，比如 course.js 里就封装了课程列表、课程详情、课程上下架等接口。views 目录按页面组织，一个路由基本对应一个 vue 文件。components 目录放公共组件，比如分页组件、上传组件、富文本编辑器封装等。

调试前端时核心是搞清楚接口是怎么连通的。看 utils 下的 request.js 封装，这里面通常做了三件事：axios 实例化、请求拦截器自动携带 Token、响应拦截器统一处理业务码并弹出异常消息。你把这三件事看明白，整个前后端数据流通的链条就清楚了。

在线上的访问路径是：浏览器请求 Vue 页面 -> Vue 根据路由加载组件 -> 组件调用 api 方法 -> axios 发送 HTTP 请求 -> 后端 Controller 接收 -> Service 处理 -> Mapper 查库 -> 数据逐层返回。这条链路看似长，但每一层职责非常清晰，排查问题就是顺着这条链路逐段确认，看断在哪一段。

3.3 核心数据表设计经验

教育培训办公系统在表设计上，有不少值得单独讲的地方。我建议重点关注几张“关系表”，它们往往是业务价值的核心。

• 用户角色关联表：用户和角色是多对多关系，这张表要联合唯一索引，避免同一种角色重复绑定。
• 课程分类表：用 parent_id 做父子级，无限分类，前端可以用递归组件套出树形菜单。
• 订单表：建议在每个订单上加一个业务订单号，由后端生成，格式比如 yyyyMMddHHmmss + 随机数，订单金额用 decimal(10,2) 而不是 float。
• 课程与讲师的关联表：一个课程可能有多个讲师，一个讲师也能带多门课程，这种关系抽成单独一张表，比在课程表里硬塞一个 teacher_id 更规范。
• 审批记录表：办公审批模块的核心，每条审批记录要关联业务类型、业务ID、审批人、审批结果、审批意见、审批时间。这样做的好处是后续要回溯“这个申请是谁批的、批了几次”，一条 SQL 就出来了。

MyBatis-Plus 还有个很实用的设计，就是逻辑删除。几乎所有业务表都建议加一个 deleted 字段，默认为0。删除数据时不执行物理 delete，而是执行 update 把 deleted 改成1。全局配置里开启逻辑删除后，MyBatis-Plus 会自动在 select 语句后面拼上and deleted=0，这样既能防止误删，也保留了数据恢复的余地。不过要记住，逻辑删除字段是全局生效的，真做统计报表时如果发现数据对不上，先查一下是不是有逻辑删除的数据被过滤掉了。

4. 核心功能模块实现与开发实战

这部分挑几个最有代表性的功能，从实现思路到代码写法，说一下我自己的做法。这些代码片段是在非常常见的场景下总结出来的，你可以对照自己手头的代码调整，不一定逐字复制，但思路是通用的。

4.1 JWT 登录鉴权与权限控制

教育培训系统有学员、讲师、管理员、教务等多种角色，登录后不能让所有接口都裸奔。常见的做法是用 JWT（JSON Web Token）做无状态认证，配合拦截器校验。

后端在用户登录成功后，利用 userId、用户名、角色标识生成一个 JWT Token，有效期一般设为 2 小时或者 24 小时。前端拿到 Token 后存在 localStorage 里，每次请求都在请求头带着Authorization: Bearer xxx。后端拦截器从请求头提取 Token，解析成功就把 userId 存入 ThreadLocal，方便后续获取当前登录用户的信息。

权限控制分两层。第一层是接口层，用拦截器做登录校验，用自定义注解做角色校验。比如给某个接口加上@RequireRole("admin")，进入方法前先判断当前用户角色是否包含 admin，不包含就直接返回“无权限访问”。第二层是菜单层，前端根据用户角色动态生成路由和菜单，不同角色登录后看到的侧边栏菜单完全不一样。

这种设计是目前后台管理系统的标准打法。要注意的是，JWT 一旦签发，在有效期内是无法主动注销的。如果你的项目要支持“管理员强制下线某个用户”，可以通过把用户状态字段置为禁用，在拦截器里再校验一次用户状态，就能实现变相注销效果。

4.2 课程报名与订单事务处理

课程报名是最典型的“写多张表”的业务，必须配合数据库事务来保证数据一致性。流程如下：

1. 校验课程是否存在且未下架。
2. 校验当前用户是否已经报名该课程，防止重复购买。
3. 查询课程价格，生成订单记录。
4. 扣减课程库存，如果库存不足要返回明确报错。
5. 生成学员的选课记录，状态为“已支付”或“待支付”，根据你设计的业务逻辑来定。
6. 若涉及营销活动（优惠券、折扣），还要在事务里处理优惠信息和实际支付金额的计算。

你把这三步看明白，整个前后端数据流通的链条就清楚了。

上面的每一步都必须出错回滚。在 Spring 里，你只需要在 service 方法上加@Transactional(rollbackFor = Exception.class)，就表示这个方法里任何一个 RuntimeException 抛出，数据库操作会一起回滚。有一个非常容易踩的坑：事务默认只回滚 RuntimeException，如果你的业务代码捕获了异常并返回了一个失败结果对象，数据库不会回滚。所以要么往上层抛出异常，由全局异常处理器统一转换为错误响应，要么在 catch 块里手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。

4.3 在线视频播放与学习进度记录

教育培训系统的视频播放，严格来说不是后端渲染视频，而是通过前端播放器去拉取视频地址。通常是后端返回视频文件的 URL（可能是本地上传的文件 URL，也可能是对象存储的私有链接），前端用 vue-player 或者原生 video 标签进行播放。

学习进度记录是个容易被忽视但很重要的功能。我推荐的做法是：前端播放器监听 timeupdate 事件，注意这里要额外注意 Vue3 的响应式特性，timeupdate 事件触发的频率非常高，每隔几百毫秒就会触发一次，如果每次都请求后端，压力太大。需要做节流处理，比如每5秒上报一次最新播放秒数，或者监听 pause、ended 事件时才把进度写入后端。后端存一张学习记录表，字段包括课程ID、章节ID、用户ID、最后播放位置、是否完成。

要注意的是，如果页面关闭时异步请求还没发出去，进度就会丢失。建议在上报进度时使用navigator.sendBeacon或者在前端组件卸载守卫 beforeUnmount 里强制上报一次，保证“已学到哪里”这个数据至少是接近实时的。

4.4 审批流模块的通用设计思路

办公审批模块，比如“讲师申请调课”“教务申请采购教具”“学员申请退费”，这些流程本质上都是同一个模型：提交申请 -> 上级审批 -> 通过/驳回。设计时如果为每个业务单独建一张审批表，后期会非常痛苦，维护成本高。

更优雅的设计是建一张通用的审批申请表，字段包含业务类型（比如 COURSE_ADJUST 表示调课、REFUND 表示退费）、业务ID（关联具体是哪条订单或哪个课程）、申请理由、审批状态、当前审批人、最终审批结果。业务详情留在各自的业务表里，审批表只是记录“谁申请了什么、批到哪一步、谁批的、批的结果是什么”。

审批完后如果需要触发后续业务动作，比如退费审批通过后自动改订单状态，可以通过消息通知或者定时任务去扫描已通过但未处理的审批单。简单场景下，直接在审批通过的方法里同步更新业务表状态也可以，但要注意做好幂等控制，防止重复处理。

这个模块的核心经验是：把“审批流程”本身做成一种数据，而不是把每一种审批做成一套代码，这样才能应对不断新增的业务形态。

5. 环境搭建、配置与部署实操

这个环节是整个项目从“能在本地跑”到“能在服务器上跑”的关键阶段。下面分为本地开发环境和服务器部署环境分别说明，每一步都给出我实际用过的方案，你可以直接参照操作。

5.1 本地开发环境搭建

本地开发需要准备的工具清单大致如下：

• JDK 1.8 或 11（对应 SpringBoot2）
• Maven 3.6+（用于后端依赖管理）
• Node.js 16+（用于前端构建和开发服务器）
• MySQL 8.0（本地数据库）
• Redis（如果项目里有验证码、缓存、Token 黑名单之类的功能，一般会用到，部分项目会默认本地不需要 Redis，需要根据你实际跑的代码情况调整）

MySQL8.0 的安装，Windows 和 macOS 都比较简单，Linux 上稍微繁琐一点，需要做用户授权和远程访问配置。如果你手头是全新的 MySQL8.0，拿到项目后第一件事是看 SQL 脚本在哪个目录，用 Navicat 或命令行执行导入即可。

一个非常容易出现的问题就是字符集。MySQL8.0 本身默认字符集是 utf8mb4，但某些安装环境下可能会因为初始化参数不一致出现乱码。我的建议是，在创建数据库时就指定字符集：

CREATE DATABASE IF NOT EXISTS edu_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

这样能最大程度避免后续插入中文数据时出现乱码。导入 SQL 时如果脚本里已有建库语句，注意你的账号是否有权限执行 CREATE DATABASE，如果没有，就只执行建表和数据部分。

后端配置文件通常是application.yml或application-dev.yml。需要重点检查这几项：数据库地址账号密码、Redis 地址（如果依赖）、JWT 密钥、文件上传路径。文件上传路径建议配成绝对路径，例如/home/edu/upload，而不要用相对路径，因为相对路径在不同启动方式下会指向完全不同的地方，踩过这个坑的人应该都懂。

前端开发环境的启动比较简单，在vite.config.js里一般已经配好了代理：

server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样你在前端请求/api/xxx时，Vite 开发服务器会自动帮你转发到后端的 8080 端口，免去了前后端跨域的烦恼。如果你遇到前端能跑、后端能跑，但一请求就报 CORS 错误，优先排查代理有没有生效。

5.2 服务器部署与 MySQL8.0 配置注意

部署到 Linux 服务器时，前后端分离项目一般是这样的套路：后端打成一个 jar 包，用 systemd 或 nohup 启动；前端用 Vite 构建生成静态文件，部署到 Nginx 的 html 目录下，Nginx 再反向代理后端接口。

后端打包前，记得把生产环境的数据库地址、上传路径这些配置写入application-prod.yml，打包命令：

mvn clean package -DskipTests

然后用 nohup 启动：

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

日志会写到 edu.log 里，排查问题时这个文件是主要依据。建议把-Xms512m -Xmx1024m加上，避免堆内存默认太小导致高并发时 OOM。

前端构建也非常简单：

npm run build

构建完成后生成 dist 目录，整个 dist 目录就是静态站点，把它拷到 Nginx 的/usr/share/nginx/html/edu下。Nginx 配置核心是两段：一段是静态页面路由，一段是接口反向代理：

location / { root /usr/share/nginx/html/edu; 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 特别重要，如果没有它，前端路由刷新页面时会直接 404。因为 Vue3 是 SPA 单页应用，路由由前端控制，刷新时浏览器请求的是实际路径，后端没有这个路径，需要把所有请求重新指向 index.html。

MySQL8.0 在服务器上部署时，我建议给 my.cnf 加一些合理的参数，别用默认配置跑。下面是一份我自己的参考配置：

[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_general_ci default-time-zone=+8:00 max_connections=500 innodb_buffer_pool_size=512M innodb_log_file_size=256M

innodb_buffer_pool_size 是 MySQL 最吃内存的参数之一，根据服务器内存大小调整。如果服务器只有 2G 内存，设置 512M 已经算高，再多就会和 Java 应用抢内存。default-time-zone 设置为 +8:00 能避免 Java 程序里new Date()和 MySQL 的 CURRENT_TIMESTAMP 时区不一致的问题，这是网上“linux安装mysql8.0”相关教程里很容易忽略的一个点。

6. 开发与运维中的常见问题排查

这部分结合我自己做过的项目，把容易出现问题的几个地方列出来，并给出排查思路。很多问题其实并不复杂，只是首次遇到时难免会有点懵。

6.1 MyBatis-Plus 分页不生效

分页不生效是 MyBatis-Plus 使用里最高频的一个问题。很多人的分页查询，第一次用查出来的数据是全量，不是因为代码写错了，而是因为分页插件没有注册到 Spring 容器里。

MyBatis-Plus 3.4+ 版本需要手动配置 PaginationInnerInterceptor，以下是常见的写法：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

新版中建议使用MybatisPlusInterceptor（而非旧的PaginationInterceptor，旧类已废弃）。如果你漏配了这段代码，调用 selectPage 时虽然能返回对象，但 total 是 0 或者查出来是全表数据。排查时先检查这个配置类是否存在。

另一个分页相关的问题是页码从 1 开始还是从 0 开始。MyBatis-Plus 默认页码从 1 开始，而很多前端组件默认第 1 页的页码也是 1，但也有部分前端组件从 0 开始。两者不匹配会导致数据差一条。我的建议是统一约定：后端接收的 pageNum 最小为 1，前端传参之前先做归一化处理，这样无论 UI 组件是什么习惯，后端都不会乱。

6.2 Vue3 中 Element Plus 组件样式不生效

Element Plus 的样式问题，最常见的场景是：页面能渲染，但按钮、表格的间距和颜色都不对，或者修改组件默认样式覆盖不掉。

原因通常是全局样式覆盖了 Element Plus 的变量，或者引入方式不正确。Element Plus 的全量引入方式是在 main.js 里：

import { createApp } from 'vue' import ElementPlus from 'element-plus' import 'element-plus/dist/index.css' const app = createApp(App) app.use(ElementPlus) app.mount('#app')

如果你按需引入，需要使用 unplugin-vue-components 和 unplugin-auto-import 这两个插件，并且在 vite.config.js 里配置组件自动导入。如果配置不齐全，组件可能渲染不出来或者报找不到组件名的错误。

还有一个很细节的坑：Element Plus 是按el-button、el-table这种方式使用组件的，但如果你在项目里自定义了同名组件，Vue 的解析优先级会导致你自己的组件覆盖 Element Plus 组件，造成样式错乱。排查时可以去开发者工具里看实际渲染出来的 DOM 标签是不是el-xxx开头的，如果不对，很可能是组件注册顺序问题。

修改 Element Plus 默认样式，比如网上常搜的“vue3修改tabs标签页样式”，最干净的做法是使用 CSS 变量，Element Plus 的每个组件都暴露了--el-color-primary、--el-border-radius-base这样的 CSS 变量，全局覆盖：

:root { --el-color-primary: #409eff; --el-border-radius-base: 6px; }

然后用深度选择器覆盖局部组件：

:deep(.el-tabs__item) { font-weight: bold; }

Vue3 的 scoped 样式配合:deep()是官方推荐的方式，它可以穿透 scoped 边界，精准作用到子组件内部的 DOM 节点。

6.3 MySQL 连接不稳定与时区问题

“数据库偶尔连不上”或“时区错误”是部署阶段的老熟人。时区问题很好识别，报错信息里如果出现The server time zone value 'XXX' is unrecognized，就说明 JDBC 连接串里的时区参数和服务器时区不一致了。

解决方法是在 JDBC 连接串中明确指定时区：

jdbc:mysql://localhost:3306/edu_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

数据库偶尔连不上的现象，更多是连接池配置问题。比如 MySQL 的 wait_timeout 默认是 8 小时，如果连接池里的连接空闲超过了这个时间，MySQL 会主动断开，而连接池不知道，下一次请求拿着旧连接去查询，就会报 Communications link failure。解决办法是把连接池的验证机制打开，同时设置合适的空闲回收周期。以 HikariCP 为例：

spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 idle-timeout: 600000 max-lifetime: 1800000 connection-test-query: SELECT 1

max-lifetime 尽量小于 MySQL 的 wait_timeout，这样可以避免拿到已经被服务端断开的连接。

6.4 前端跨域与代理问题

本地开发跨域问题一般靠 Vite 代理解决，但生产环境如果 Nginx 代理配置不对，同样会有问题。常见的报错是 Access to XMLHttpRequest has been blocked by CORS policy。

排查思路按两层走。第一层，看浏览器请求的 URL 是不是真的打到了后端接口。在开发者工具的 Network 面板里找到那个请求，如果 URL 前面带了正确的 /api 前缀，说明前端请求是正常的，问题出在后端。第二层，看后端是否返回了 CORS 响应头。如果是“通过 Nginx 反向代理”，优先在 Nginx 里统一加 CORS 头，而不是在后端代码里配置 CorsFilter，因为有些框架的后端 CORS 配置和拦截器顺序冲突，反而会造成响应头缺失。

如果项目没有走 Nginx，而是前后端各跑各的域名，那后端需要自己处理跨域。SpringBoot 中一个常用方案是实现 WebMvcConfigurer 并添加跨域映射：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowCredentials(true) .maxAge(3600); } }

注意 allowCredentials(true) 时，allowedOrigin 不能直接用*，需要用 allowedOriginPatterns 以*实现动态放行。这一行不太起眼，但很多跨域问题都栽在这里。

7. 团队协作与后续扩展建议

项目跑起来还只是开始，真正考验一个系统价值的是后续维护和扩展。基于这套教育培训办公系统的架构，下面几条扩展路径都是比较顺的。

第一个方向是增加直播教学功能。教育机构只靠录播视频是不够的，直播意味着需要对接 WebRTC 或第三方直播服务商，要做直播房间、聊天室、在线互动、回放生成等功能。这会对系统的实时消息能力提出新要求，可以考虑引入 WebSocket 或消息队列实现弹幕和互动通知。

第二个方向是增加营销模块。比如课程优惠券、拼团活动、邀请有礼、积分商城。这些功能会涉及更复杂的金额计算和库存扣减，需要把优惠计算模块单独抽出来，避免把各种逻辑堆在订单 Service 里。

第三个方向是完善数据统计与报表。教育行业的运营看板通常需要展示完课率、续费率、退费率、热门课程 Top10、讲师授课饱和度等指标。这套系统的数据表结构基本能支撑这些需求，但统计 SQL 会越来越复杂，建议提前把定时统计任务（比如每天凌晨统计前一日数据）用 Spring 自带的 @Scheduled 或引入 xxl-job 这类分布式调度平台来做。

第四个方向是移动端适配。很多学员习惯用手机上课，但管理后台用手机操作的机会反而不多。所以移动端可以只对学员端开发小程序或 H5，后端接口复用现有的，只是把授权方式从账号密码换成微信授权登录。

如果后面要接手一个团队并行开发，建议尽早统一几个规范：接口返回结构、状态码定义、异常处理方式、数据库命名规则、前端组件命名规则。这些看似琐碎，却是团队协作效率的关键。我自己见过太多项目因为没人定规范，导致一个字段一会儿叫 courseId 一会儿叫 course_id，前端对接口时对到怀疑人生的场景。

8. 写在最后的一点体会

这套基于 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 的线上教育培训办公系统，从技术栈到业务模块都是很典型的真实项目样本。它不会像课程作业那样只是“增删改查四件套”，而是通过角色权限、订单事务、审批流、学习进度这些细节，逼你把工程化思维落到实处。

我个人的体会是，拿到这类源码时，不用急着全部跑通，先把角色权限和数据表结构吃透，再挑一个完整业务闭环逐步调试，最后再去做部署上线。等你把一个闭环从前端组件点到后端表结构整条链路走完，这个项目对你来说才算真正有价值。

最后再分享一个小技巧：这类项目里，用户表、订单表、课程表的数据量会快速增长，MySQL8.0 虽然性能不错，但后续如果表数据量超过百万行，建议尽早考虑分库分表和缓存层。现在项目刚起步时不用过度设计，但数据库索引要根据实际查询提前建好。比如订单表上 userId 和 courseId 的组合查询很常见，就值得加一个联合索引；课程表上状态字段和上下架时间的查询，也要设计好索引策略，否则后期一张报表查询就能把数据库拖垮。希望这套源码能帮你少踩一些坑，真正沉淀出自己的全栈项目经验。