企业官网建设流程全解析

企业级智能学习平台管理系统，光看标题，就是一套典型的 SpringBoot + Vue + MyBatis + MySQL 组合的 Java 全栈项目。这几个月我在公司内部牵头做技术培训平台升级，正好就是基于这套技术栈从零搭的，所以看到这个标题格外有感触。市面上不少自称“企业级”的源码，实际就是课程管理系统套个壳，真正能在生产环境扛住并发、理清权限、方便二次开发的很少。这篇我就结合自己实际搭建和维护这套系统的经验，把整体架构设计、核心模块拆解、关键代码实现细节，还有我踩过的那些坑，一次性说清楚。不管你是刚学完 SSM 准备进阶的学生，还是公司里想搞一套内部培训系统的开发，这篇都能给你一个可以直接参考的完整方案。

1. 项目整体架构与设计思路拆解

先聊技术选型。很多人有个误区，觉得“企业级”就等于要用微服务、要用 Spring Cloud、要上 Redis 集群。我做过几个企业内部系统，包括这个学习平台，最深的体会是：技术复杂度应该跟业务复杂度匹配，而不是跟所谓的“企业级”标签匹配。一个几百人、几千人规模的企业内部学习平台，单体应用加合理优化，完全够用，强行上微服务反而把部署、监控、排错的成本抬上去了。

1.1 为什么是SpringBoot+Vue+MyBatis+MySQL这套组合

这四样东西，拆开看都是各自领域里的“默认选项”，合在一起就是一套非常成熟的互联网应用通用解法。

SpringBoot负责后端基础框架。它对Spring生态做了大量自动化配置，我不用再写一堆XML配置文件。内嵌的Tomcat也让部署变得极其简单，一个java -jar命令就能启动。对企业内部系统来说，快速交付、稳定运行是第一位，SpringBoot正好命中这两点。

Vue负责前端交互层。它用组件化开发和响应式数据绑定，开发和维护体验比传统的JQuery时代好太多。特别是做这种带课程目录、视频播放、在线考试、后台管理的系统，前端逻辑很复杂，Vue的组件化能把复杂度拆解得非常干净。Element UI这类现成组件库一配，表格、表单、弹窗、分页这些后台管理页面的“标配”功能很快就能搭出来。

MyBatis负责数据持久层。有人可能会问，为什么不选 Spring Data JPA？我的理由是：企业内部系统报表查询多、统计逻辑复杂，经常要写多表联查。MyBatis 把 SQL 控制权完全还给开发人员，每条 SQL 都在自己手里，该怎么优化、怎么加索引，心里一清二楚。JPA 在简单 CRUD 上效率高，但一旦遇到复杂查询，凑 JPQL 反而耗时，性能调优也绕了一层。

MySQL是存储层。开源、稳定、生态好、资料多，招人容易，出了问题随便搜一下就有答案。对于学习平台这种读写均衡、数据量可控的系统，MySQL 用 InnoDB 引擎加合理索引设计，性能完全没有瓶颈。

1.2 前后端分离下的工程结构设计

这个系统的工程结构，我建议一开始就按前后端彻底分离来组织，前端一个仓库，后端一个仓库，用接口文档约定契约。下面是我实际使用的后端包结构，踩过几轮坑之后沉淀下来的，按这个结构，功能边界非常清楚：

├── src/main/java │ └── com.company.learning │ ├── LearningApplication.java // 启动类 │ ├── common // 通用模块 │ │ ├── result // 统一返回包装类 │ │ ├── exception // 全局异常处理 │ │ ├── utils // 工具类 │ │ └── constant // 常量定义 │ ├── config // 配置类 │ │ ├── WebMvcConfig.java // MVC配置、拦截器注册 │ │ ├── MyBatisConfig.java // MyBatis配置 │ │ └── CorsConfig.java // 跨域配置 │ ├── controller // 控制层 │ │ ├── admin // 后台管理接口 │ │ └── api // 前台用户接口 │ ├── service // 业务逻辑层 │ │ ├── impl // 实现类 │ │ └── ... │ ├── mapper // MyBatis持久层接口 │ └── entity // 实体类 ├── src/main/resources │ ├── mapper // MyBatis XML映射文件 │ ├── application.yml // 配置文件 │ └── sql // 数据库初始化脚本

前端结构就按 Vue 官方推荐的方式拆，views 目录下按模块分页面，router 里做路由配置，store（Vuex/Pinia）管全局状态，api 目录统一封装 axios 请求。有一个细节特别建议新手注意：请求的封装一定要统一做，比如统一加 token 请求头、统一处理 401 超时跳转、统一提示接口异常。如果每个页面自己写一遍 axios 调用，后端接口参数一变，前端得改几十处，维护成本直线上升。

前后端分离开发，最大的坑是跨域问题。分离环境下，前端跑在 8080 端口，后端跑在 8081 端口，浏览器同源策略直接拦截。我的做法是在后端配置全局 CORS 处理，允许指定来源跨域请求。这个配置很简单，但有个细节要注意：allowedOriginPatterns 不能配成 “*”，否则后面带 cookie 凭证时会被浏览器拒掉，这个我在第 4 部分会专门展开讲。

1.3 容器化与部署链路设计

真正跑到“企业级”这一步，部署方案不能省。我这边是前端构建成静态资源后用 Nginx 托管，后端打包成 jar 跑 systemd 服务，数据库独立一台机器。再进一步就是用 Docker 跑容器，docker-compose 一键拉起前端容器、后端容器、MySQL 容器，内部网络用服务名互相访问，减少 IP 变更的干扰。

这套部署结构的好处是：Nginx 负责静态资源托管和反向代理，前端和后端通过 /api 路径区分，后端服务可以随时升级重启，对用户无感知。后面如果并发量上来了，后端多开几个实例挂到 Nginx 负载后面就行，改动成本非常低。

2. 核心需求解析与数据库设计要点

回到业务本身。既然做“智能学习平台”，核心就是两件事：一是管内容，课程、章节、视频、文档；二是管用户，员工账号、学习记录、考试成绩、学习时长统计。这两块业务对应的数据库设计，是整个系统能不能优雅运行的地基。

2.1 用户认证与权限控制模型

企业系统跟个人网站最大的区别，就是权限体系。个人网站通常就两个角色——普通用户和管理员，用一个字段区分就够了。企业系统至少有这三种角色：普通学员、讲师/内容管理员、系统管理员。复杂的可能还有部门管理员、培训专员。所以权限模型必须用经典的 RBAC（基于角色的访问控制）模型。

核心表结构是五张表：

• sys_user：用户表，存账号密码、姓名、部门、状态。密码存的是 BCrypt 加盐哈希，明文密码在任何时候都不能落到数据库里。
• sys_role：角色表，定义系统中有哪些角色。
• sys_user_role：用户角色关联表，一个用户可以有多个角色。
• sys_menu：菜单权限表，定义系统有哪些菜单、按钮、接口权限点。
• sys_role_menu：角色权限关联表，把权限点分配给角色。

RBAC 的好处是权限调整非常灵活。给某个员工开培训管理权限，不用改代码，管理员在后台给他绑定讲师角色就行。权限粒度还能细化到按钮级，比如“课程发布”按钮只有管理员能看到，讲师只能看到“课程编辑”。

学员端和后台端建议分开设计。前台用户默认登录后只能看分配给自己的课程、提交考试、查看成绩；后台用户按角色看对应的管理页面。Vue前后端都要做权限控制，后端用拦截器校验角色，前端用动态路由按权限生成菜单，两边的权限规则保持一致。

2.2 课程与学习进度模块设计

课程内容管理是这个系统的核心资产。我的表设计是三层结构：课程表（course）→ 章节表（chapter）→ 学习小节表（lesson）。课程表存课程名称、封面图、简介、讲师ID、课程分类、状态，章节表存课程下的章节排序，小节表存视频地址、文档地址、小节名称、时长。

学习进度记录是这个系统最有价值的数据。员工点开视频、看了几分钟、有没有看完、看完几遍，这些数据是企业培训管理者非常关心的。我设计了一张study_record表，记录每个用户、每门课程、每个章节的学习状态，按 0%（未开始）、50%（学习中）、100%（已完成）三档记录。视频播放器的进度监听接口，每 15 秒上报一次当前播放位置，后端更新最近学习位置和最后学习时间。这套逻辑是关键：员工请假、断网、换设备，再回来能接着上一次的位置继续看。

统计报表部分，根据study_record按天聚合，就能算出人均学习时长、课程完成率、部门学习排行这些企业管理者最爱看的数据。聚合逻辑放在后端统一处理，前端只负责展示，避免把统计压力压到浏览器上。

2.3 试题与在线考试模块设计

在线考试模块，千万别做成简单的“出题-答题-给分”。企业级考试还要考虑题库分类、试卷组卷策略、防作弊、成绩归档、补考等场景。我设计的核心表是这几张：

• exam_question：试题表，分单选题、多选题、判断题、简答题。题目归属科目、难度等级、知识点标签都存进去。
• exam_paper：试卷表，定义试卷名称、考试时长、总分、及格分、状态。
• exam_paper_question：试卷题目关联表，关联试卷和试题，定义每题的分数和排序。
• exam_record：考试记录表，每次考试的唯一记录，包含考生 ID、试卷 ID、开始时间、交卷时间。
• exam_answer：答卷表，记录每道题的作答答案和得分。

判分逻辑分两类：客观题（单选、多选、判断）交卷时自动判分，简答题需要人工评分。交卷时客观题判分的结果要同时写入考试记录表的总分字段，方便后续按总分排名统计。试卷设计上，常见能力是固定试卷（所有考生同一套题）和随机组卷（从题库按规则抽题，每个考生的题目顺序都不同），在企业防作弊场景下，随机组卷几乎是刚需。

2.4 数据库索引与事务设计要点

表结构设计完，还有两个关键细节。

第一个是索引。这是系统运行性能的保障。学习记录表要频繁按“用户ID + 课程ID”查询进度，就必须建联合索引(user_id, course_id)；考试记录表要按“试卷ID + 用户ID”查成绩，同样加联合索引。如果不加索引，数据量一上来，即使只是几千条记录，查询也会慢得明显。另外所有表的主键尽量用自增 ID，方便索引维护，不要用 UUID 当主键，插入随机性会让 B+ 树频繁分裂。

第二个是事务。凡是涉及“多表写操作”的接口，必须加事务控制。比如用户提交考试答案，一次请求会涉及多个表的写入。如果没有事务，中途某个环节出错，就可能出现“分数记上了，但答案记录没写进去”这种数据不一致问题。SpringBoot 里加事务非常简单，在 Service 方法上标注@Transactional注解即可。但有几个细节：事务默认只对 RuntimeException 回滚，抛异常时要注意类型；事务方法不能同类内调用，会被代理机制跳过；长事务不要在方法里做耗时的外部接口调用，否则数据库连接池会被占满。

3. 核心功能实现与关键代码解析

这章我会把系统里最关键的几个功能点，从零到一讲清楚。每个功能点都不只是贴代码，而是把“为什么这么做”背后的逻辑也一并说透。

3.1 基于JWT的用户登录态设计

企业系统登录方案，传统方式是 Session + Cookie，但前后端分离架构下，更推荐 JWT（JSON Web Token）无状态认证。JWT 把用户ID、用户名、过期时间等必要信息编码进 token 里，后端验签通过即可，不必依赖服务端会话存储。

认证流程是这样的：

1. 用户提交账号密码，后端用 BCrypt 校验密码。
2. 校验通过后，生成一个 JWT token，包含用户ID、用户名、过期时间（我一般设为 24 小时），用服务端密钥签名。
3. 把 token 返回给前端，前端存在 Vuex（或 Pinia）里，同时持久化到 localStorage。
4. 前端每次请求 axios 通过请求拦截器在 Header 里加上Authorization: Bearer <token>。
5. 后端用拦截器或过滤器解析 token，验证合法性，然后把用户信息放进 ThreadLocal。

后端 JWT 工具类的核心代码，我一般是这样写的：

public class JwtUtils { private static final String SECRET = "your-256-bit-secret-key"; private static final long EXPIRE = 24 * 60 * 60 * 1000L; public static String createToken(Long userId, String username) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

使用 jjwt 库实现。注意 SECRET 不能直接写死在代码里，应该放到配置文件或环境变量中。实际项目中还可以把 SECRET 长度控制在 32 字节以上，避免被暴力破解。

用户信息的传递用 ThreadLocal。登录态校验通过后，我写个UserContext工具类，把当前登录用户ID放进去，后面所有 Service 层代码都可以用UserContext.getUserId()获取当前操作人，不用每个接口都把用户ID作为参数往上传，清爽得多。但记住请求结束必须 remove，否则线程池复用会串用户，这是线程安全问题。我见过线上事故就是因为忘了清理 ThreadLocal，A 用户看到了 B 用户的数据。

3.2 前端动态菜单与路由权限设计

前端权限控制，不能简单地把菜单写在路由表里。不同角色应该看到不同的导航菜单，前端要做的是根据后端返回的权限列表，动态生成路由和菜单。

我的方案是：用户登录成功后，调用后端/getUserMenus接口，拿到当前用户可访问的菜单/权限列表。前端把这份列表存到 Vuex/Pinia，用它的数据去动态添加 Vue 路由（router.addRoute），同时根据异步路由配置生成菜单栏。

前端路由要区分静态路由和动态路由。静态路由只管登录页、首页这些所有用户都能访问的页面。动态路由是一个“异步路由映射表”，每个路由项都带permission标识，根据接口返回的权限列表过滤后再注册。员工登录进来只看到“我的课程”“在线考试”，管理员登录进来看到“用户管理”“课程管理”“考试成绩”等管理入口。

// 动态路由注册的核心逻辑 const asyncRoutes = [ { path: '/course', name: 'CourseManage', component: () => import('@/views/admin/course/CourseManage.vue'), meta: { permission: 'admin:course:list' } // 接口返回的权限标识 } ]; function generateRoutes(permissions) { const accessedRoutes = asyncRoutes.filter(item => { return permissions.includes(item.meta.permission); }); accessedRoutes.forEach(route => router.addRoute(route)); return accessedRoutes; }

服务端在返回菜单权限前做一次过滤。用户没有“用户管理”权限，接口里就没有这条记录，前端路由自然不会注册。前端隐藏只是优化体验，真正的安全边界一定在后端，前端校验代码可以随时被绕过，后端接口必须用拦截器再次校验权限，这两层是配套工作的。

3.3 视频课程播放与防盗链方案

课程视频是学习平台的重头戏。视频管理有两条路可选：

一是直接存储到本机或云存储，前端通过 video 标签播放 MP4 文件。实现简单，但公司内网环境、带宽有限的情况下，多人同时在线播放会把出口带宽打满。

二是用 HLS 流媒体方案。把视频切片成 .m3u8 + .ts 文件，由 Nginx 配置 RTMP/HLS 模块或者专门的流媒体服务提供播放，前端用 hls.js 播放。这个方案能根据网络情况自动切换清晰度、拖动进度条更快，也方便后续做多码率适配和防盗链。

企业学习平台视频还有一个更实际的需求：不同员工可以看到不同的课程视频，视频地址不能直接暴露在源码里。我的做法是，课程详情接口不直接返回视频的完整 URL，而是返回一个有时效性的签名播放地址。比如/api/video/play/{lessonId}?token=xxx&expire=xxx，后端在校验登录态和课程权限后，才生成一个临时有效的视频访问地址返回给前端播放器。这样做的好处是，员工直接复制视频链接分享给同事也看不了，有效期一过就得重新请求，听课权限牢牢记在后端。

3.4 我的Batis动态SQL实现复杂查询

后台管理中“按条件分页查询”是最高频的操作。比如课程管理需要按课程名称模糊搜索、按课程分类筛选、按发布状态查询，还要支持分页。如果用注解写 SQL，条件一变就得改代码。用 MyBatis 的动态 SQL，把这些判断统统交给 XML 里的标签处理。

下面是我课程分页查询超实用的一条 SQL：

<select id="selectCoursePage" resultType="com.company.learning.entity.Course"> SELECT c.*, u.real_name AS teacherName FROM course c LEFT JOIN sys_user u ON c.teacher_id = u.id <where> <if test="courseName != null and courseName != ''"> AND c.course_name LIKE CONCAT('%', #{courseName}, '%') </if> <if test="categoryId != null"> AND c.category_id = #{categoryId} </if> <if test="status != null"> AND c.status = #{status} </if> </where> ORDER BY c.create_time DESC </select>

这里的<where>标签会自动处理 AND 前缀问题，第一个条件成立时自动省略开头的 AND。分页我用 PageHelper 插件，在 Service 层调用PageHelper.startPage(pageNum, pageSize)，紧接着的一句查询会自动拼上 LIMIT，并且返回的 PageInfo 对象里自带总条数、总页数等数据，不用自己写 COUNT 查询。

分页插件一定要注意：PageHelper 的分页参数和查询语句之间不能穿插其他 SQL 操作，否则分页会拦截错 SQL。另外实际配置的时候，pagehelper.reasonable=false不要轻易改成 true，否则页码越界会被悄悄纠正，前端拿到的页码和数据对不上，反而让人困惑。

3.5 统一返回格式与全局异常处理的规范做法

前后端分离开发，规范化的接口返回格式是减少联调争执的利器。我定义统一的返回结构Result，所有接口返回的数据都包装成这个结构：

{ "code": 200, "message": "操作成功", "data": { ... } }

code=200代表成功，非200代表业务异常（401未授权、403无权限、500系统异常等）。前端在 axios 响应拦截器里统一判断 code，等于200就取 data 渲染页面，不等于200就弹出消息提示并跳转登录页。

全局异常处理用 Spring 的@RestControllerAdvice。好处很直接：后端代码不用每个接口都 try-catch。业务异常抛出BizException("课程不存在")，全局处理器统一捕获并返回给前端：{"code": "400", "message": "课程不存在"}。系统未知异常也统一处理，记录日志的同时返回友好提示，避免把堆栈信息直接吐给浏览器（既不好看也不安全）。

这个机制写一次，全项目受益。我见过不少项目接口返回格式五花八门，有的成功返回对象，失败返回字符串，前端每个接口都得单独处理，坑得不行。统一返回格式应该作为所有接口的硬性规范。

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

最后这部分，我整理了实际开发这套系统时碰到的高频问题。排查思路和解决方案都直接给出来，多数问题是这个技术栈组合特有的。

4.1 环境与构建阶段高频问题

前端启动报错“Module not found: Can’t resolve ‘element-ui’”，这通常是对应依赖没装，执行npm install element-ui -S重新装上就好。更隐蔽的坑是：本机 Node 版本过高，跟旧版 Vue CLI 或 node-sass 不兼容导致构建崩溃。我的建议是直接用 nvm 管理 Node 版本，项目用一个固定的 LTS 版本，避免“我这能跑你那就报错”的尴尬。

后端启动报“Failed to configure a DataSource”，八成是application.yml里的数据库连接配置不对。重点检查几项：MySQL 服务是否启动、数据库名是否正确、账号密码是否匹配、时区参数是否加了serverTimezone=Asia/Shanghai。加时区参数是个非常容易忽略的细节，MySQL 8.x 连接串不带时区会直接报错。

还有一个我必须提醒的问题：MySQL 8.x 跟 5.x 的驱动不一样。连接 MySQL 8 要用com.mysql.cj.jdbc.Driver，用老驱动的com.mysql.jdbc.Driver会报警告甚至连接失败。项目上尽量在 pom.xml 里锁定 mysql-connector-java 的版本号，避免构建时拉了不确定的版本。

4.2 MyBatis经典难点：映射与SQL排查

MyBatis 最常见的报错是Invalid bound statement (not found)。这个错我十次里有八次是以下几种原因：XML 文件的 namespace 跟 Mapper 接口没对全、接口方法和 XML 里的 id 不一致、XML 文件没放在resources/mapper目录下导致没被扫描到。排查方法就是按这三步走，基本都能定位。

application.yml里配置下面的参数，开发阶段建议打开：

mybatis: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath:mapper/*.xml type-aliases-package: com.company.learning.entity

map-underscore-to-camel-case: true这个配置是真的能救命。数据库字段是下划线命名create_time，实体类是驼峰命名createTime，打开这个开关后 MyBatis 自动映射，不然查出来的数据 createTime 全是 null。

打开日志输出之后，控制台会打印每一条 SQL 和参数值。排查复杂查询结果不对时，我习惯直接把这个 SQL 复制到 Navicat 里手动执行一遍，对比结果差异。这个方法比盯代码高效十倍，因为能立刻知道是 SQL 写错了还是参数传错了。

动态 SQL 里用<if test="status != null">判断时，注意空字符串的问题。前端传空字符串过来时 status 不为 null，判断会通过，但查出来的结果可能不对。稳妥的做法是同时判断非空字符串，这也是我在 3.4 节 SQL 里为什么写两段条件的原因。

4.3 Vue与SpringBoot联调典型问题

联调阶段最高频的错误是 401。现象是前端请求带上了 token，后端还是返回“未授权”。排查重点：检查前端请求拦截器是否正确读到了 token——很多项目把 token 存到了 sessionStorage，但页面刷新后 Vuex 状态重置了，拦截器就取不到 token，实际请求头里没带。解决方案是刷新后从 localStorage 重新初始化 Vuex 里的 token。

第二个高频问题是跨域。前后端分离开发时，前端 8080 端口访问后端 8081 端口，浏览器报 CORS 错误。我推荐用后端统一 CORS 配置来解决：

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

生产环境如果走 Nginx 反向代理，前端和后端是同一个域名不同路径，其实不存在跨域问题，但开发环境分开部署就绕不开。注意allowCredentials和allowedOriginPatterns必须搭配使用，两个都配了才能带 cookie 凭证。另外这里是个容易踩坑的地方：如果用了 Spring Security 做认证，CORS 配置可能被 Security 的过滤器链拦截，需要在 Security 配置里再配一遍cors()开启。这两个权限框架叠加导致的跨域问题，往往排查大半天才明白。

第三个常见问题是 Vue Router 的 history 模式刷新 404。开发环境没事，部署到 Nginx 后，访问/course/manage页面刷新就 404。原因是 history 模式下，前端路由走的是浏览器的 URL 路径，刷新时浏览器向 Nginx 请求这个真实路径，Nginx 找不到对应文件就返回 404。解决办法是 Nginx 配置 try_files 把所有路径都回退到 index.html：

location / { try_files $uri $uri/ /index.html; }

如果前端部署在子路径（比如根目录下的 /admin），对应的 location 配置也要调整 base 和 try_files 的路径。这些联调细节，踩过一次基本就会形成肌肉记忆。

4.4 构建与部署阶段的生产经验

mvn package打包报错是一个新手常见问题。优先检查 Maven 仓库是否配置了国内镜像，否则从国外中央仓库拉依赖能慢到怀疑人生。配置阿里云镜像后，速度提升非常明显。

后端打出来的 jar 包运行前，记得确认打包结果里包含的是最新代码。我犯过一个印象深刻的错误：改了代码但忘记重新打包，直接把旧 jar 重启了，排查了半天才发现是白忙活。这个“低级错误”在忙乱时最容易出现，建议打包后看一眼 jar 文件的时间戳。用一个简单的脚本整合打包-上传-重启的流程，比手动操作可靠得多。

生产环境数据库连接池、JVM 参数这些也要提前设置。比如 Tomcat 默认最大线程数 200，如果公司几百号人同时在线看视频、做题，峰值压力下连接池爆掉是很正常的。提前把server.tomcat.max-threads、maximum-pool-size（HikariCP）适当调大，并设置合理的超时时间和队列容量。当然系统的瓶颈不一定在后端，如果有条件，课程视频尽量挂到专门的静态资源服务上，别让后端应用服务器既处理业务请求又扛视频流。

5. 一些个人心得与建议

整套系统从零搭建到上线，我最大的体会是：不要迷信“企业级”三个字，要把精力放在“业务闭环”上。学习平台真正难的不是 CRUD，而是把“员工学习—进度追踪—考试考核—成绩反馈”这条完整的链路打通。权限、事务、索引、异常处理这些基本功要扎实，它们是系统稳定性的基石。

对于想在这个项目上二次开发的朋友，我建议按这个顺序去改：先把用户权限体系吃透，这是所有功能的骨架；再改课程模块，增加你们自己的业务字段；最后再做报表模块，把学习数据真正用起来。如果想把系统做成微服务架构，也不是不行，但要意识到分布式的复杂度必须建立在现有单体已经把核心业务跑顺的前提下。我把方案和代码都整理在下面了，需要的直接拿去参考。> 提示：本篇文章对应的源码包，亲测在 JDK 8、MySQL 5.7/8.0、Node 14+ 环境下可以完整跑通。前后端代码、数据库初始化脚本、部署说明文档都在包里，其中有一份部署文档是我在真实服务器上一步步验证过写出来的。如果你在搭建过程中遇到跟文章里不一样的问题，欢迎随时交流各自的解决方案。