Spring Boot+Vue学生学习平台管理系统：从设计到部署全攻略

这个题目我在帮人做毕业设计辅导时接过不止一次。Spring Boot + Vue 的学生学习平台管理系统，几乎可以算高校软件类毕设里的"常青树"选题了。原因很简单：它技术栈主流、业务场景清晰、前后端分离的架构能完整展示一个工程师的基本功，而且从需求分析到数据库设计、从接口开发到部署上线，整条链路都能在一套系统里走通。这篇文章我就以一套实际交付过的某高校学生学习平台管理系统为蓝本，把需求拆解、表结构设计、前后端关键实现、服务器部署，以及那些只有自己亲手跑一遍才会撞上的坑，全部摊开来讲。不管你是正在做同类毕设，还是想拿一个完整项目练手入门，这篇都能当作一份可直接参照的实操笔记。

1. 项目定位与核心需求拆解

1.1 这个平台到底要解决什么问题

很多同学拿到"学生学习平台管理系统"这个题目，第一反应是"不就是个网课网站吗"，然后就开始闷头写代码。这是最大的误区。毕设项目评分的重点，从来不是页面好不好看，而是需求分析是否完整、模块划分是否清晰、技术选型是否有说服力。

我习惯在动手之前先画一张用户故事图。这个平台的核心用户有三类：学生、教师、系统管理员。三类角色对应的核心诉求完全不同：

需求拆到这个粒度，后续的数据库设计和接口设计就顺理成章了。我当时给这套系统的定位是：以课程为中心，串联"教、学、练、考、评"五个环节。所有的功能模块都围绕这条主线展开，而不是功能堆砌。这也是答辩时老师最爱问的问题——"你这个系统的核心业务逻辑是什么"，如果你能一句话说清，印象分会高不少。

1.2 技术选型为什么是 Spring Boot + Vue

选这套技术栈，不是因为它"流行"，而是因为它确实最适合这类项目，我一个个说。

后端用 Spring Boot：它内置 Tomcat，不用单独配 Web 服务器；Starter 机制把常用的整合配置都封装好了，加依赖就能用；而且 Spring 家族的生态成熟，网上资料多，遇到问题搜得到答案。对毕设来说，Spring Boot 的上手成本和学习回报比是最划算的。

前端用 Vue：对比原生 JS 或者 JSP，Vue 的组件化开发方式让页面复用变得非常舒服——比如学生列表、课程卡片、分页组件这类东西，写一次到处用。配合 Element UI 这类组件库，后台管理页面的表单、表格、弹窗交互基本就是"搭积木"。

数据库选 MySQL：业务数据是典型的结构化数据，用户、课程、作业、成绩之间关联关系明确，用关系型数据库天然合适。再加一个Redis做验证码缓存和登录 token 的会话管理，这套组合是这类系统的标准答案。

前后端分离还有一个隐藏好处：彻底解耦，协同开发效率高。前后端各跑各的端口，通过 RESTful 接口通信，只要接口约定先定好，前端同学和后端同学可以并行开发互不阻塞。部署时也可以分别扩展——学生访问量大就多开几个前端节点，后端压力大就专门优化接口性能，互不干扰。

2. 数据库设计与核心模块实现

2.1 角色权限与用户模块设计

这套系统的表我一共设计了 12 张，不多不少，刚好覆盖所有功能又不冗余。设计原则就一句话：先画出业务流程图，再反推需要哪些表，表的字段只存业务需要的字段，不要提前设计"可能以后会用"的字段。

用户相关的表是核心中的核心。我当时设计了sys_user表，字段包括主键 id、用户名、密码、真实姓名、邮箱、手机号、头像地址、角色类型、所属学院 id、创建时间。密码字段有个细节必须注意：存的是 MD5 加盐后的密文，绝对不允许明文入库。测试阶段很多人图省事直接明文存，一旦系统上线被脱库，用户的密码习惯（很多人所有平台用一个密码）会连锁出事。

角色权限这里，我采用了最简单也最稳定的方案：单用户单角色，不引入 RBAC 权限模型。因为业务场景里不存在"一个人既是老师又是学生"或者"给老师单独分配某一个按钮权限"这种需求。简单的一个role字段（1=管理员，2=教师，3=学生）配合后端拦截器就能解决全部权限问题。如果你在答辩时主动说出"我评估业务场景后刻意简化了权限模型"，这体现的是你在做技术取舍，而不是能力不足。

学生选课关系用一张course_selection关联表实现，字段是 id、学生 id、课程 id、选课时间、状态。这是典型的多对多关系的标准处理方式——学生和课程之间不直接外键关联，而是通过中间表解耦。后续要加"退课""成绩评定"等功能，直接在中间表加字段就行，不用动主表结构。

2.2 课程、作业与考试模块的表结构

课程表course的字段设计要能支撑前台展示和后台管理两个视角：课程名称、课程封面图、课程简介、授课教师 id、所属学院 id、上课时间、上课地点、选课人数上限、课程状态（草稿/已发布/已结课）、创建时间。注意这里的授课教师 id 是一个逻辑外键——我只在代码层面关联，数据库里不建物理外键约束。

这是我踩过坑之后总结出来的经验。毕设阶段数据量小，物理外键看起来"正规"，但会给后续的删除操作、数据迁移、批量导入带来很多麻烦。比如你要删一个教师，物理外键约束会挡住你不让删，你只能先去删课程、删关联表，一层层往下拆。逻辑外键配合后端校验，既保证数据一致性，又能灵活处理业务操作。

作业模块我拆成两张表：homework（作业基本信息：所属课程、标题、要求、截止时间、发布教师）和homework_submission（学生提交记录：作业 id、学生 id、提交内容、附件地址、提交时间、得分、批改状态、教师评语）。拆两张表的原因很简单：一个作业会有几十个学生提交，是一对多关系，不拆的话数据冗余会非常严重。另外我把"得分"和"批改状态"设计在提交表里而不是作业表里，因为不同学生提交的批改进度是独立的——A 同学提交了但还没批，B 同学已经批完了，状态不能用一个字段统一表示。

考试模块类似，exam表 +exam_question表 +exam_answer_record表。考试表存基本信息（所属课程、名称、开始/结束时间、时长、总分）；题目表存题目内容、选项、正确答案、分值、题型；作答记录表存每个学生每一道题的选择和得分。这里有一个只有实测才有体会的细节：在线考试一定要做"时间到自动交卷"和"防重复提交"双重保障。前端倒计时结束自动提交是理想情况，万一学生页面卡了没触发，后端必须在交卷接口里校验当前时间是否超过了考试结束时间，超时就拒绝接收答卷。

2.3 学习资源与互动模块

除了正经的课程考试，学生的"学习平台"体验还需要资源下载和互动答疑。我加了resource表（学习资料：所属课程、资料名称、文件地址、上传教师、上传时间、下载次数）和discussion表（留言讨论：所属课程、发布用户 id、内容、回复父 id、创建时间）。

互动这块有一个设计要点值得分享：回复采用父子 id 结构，一条主评论下面挂若干条回复，每条回复都可以通过父 id 找到上一级。这样做的好处是前端渲染评论树非常方便——不用递归查询，先按课程查出所有评论，在内存里按父 id 分组拼成树形结构再返回。数据量大了以后性能也扛得住。

资源文件的存储路径我建议存相对路径而不是完整路径。比如/uploads/resource/20240512_xxx.pdf，而不是D:/project/files/20240512_xxx.pdf。前者在换服务器、迁移部署时只需把整个 uploads 目录拷走即可，后者一换环境路径全断。这类"上线才会暴露的问题"，在数据库设计阶段就规避掉，是最省事的。

3. 后端 Spring Boot 关键实现与接口设计

3.1 项目分层与统一响应封装

后端工程我按标准的三层架构来组织：Controller 层（接收请求、参数校验、返回结果）、Service 层（业务逻辑、事务管理）、Mapper 层（数据持久化，用 MyBatis-Plus）。额外再加一个 config 包放配置类、common 包放统一返回结果和异常处理、utils 包放工具类。

这里必须说一个影响开发效率的决策：用 MyBatis-Plus 而不是原生 MyBatis。它的 BaseMapper 内置了增删改查、分页查询、条件构造器，单表操作一行代码都不用写 SQL。平台里 80% 的查询就是就是"按课程 id 查作业列表"这种单表操作，用 LambdaQueryWrapper 三行解决。剩下的多表联查、统计报表再手写 XML。这样又省时间又不容易出错。

统一响应封装是后端所有接口的"门面"，我定义了一个泛型结果类：

@Data public class Result<T> { private Integer code; // 200 成功，其他为失败 private String message; // 提示信息 private T data; // 业务数据 public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMessage("操作成功"); r.setData(data); return r; } public static <T> Result<T> error(String message) { Result<T> r = new Result<>(); r.setCode(500); r.setMessage(message); return r; } }

你可能觉得封装一个 Result 类是"多此一举"，但实际联调时你就知道它的价值了。前端 axios 拦截器只需要判断一次res.data.code === 200，成功就走成功回调，失败就统一弹错误提示。如果没有统一格式，前端每个接口都要单独处理不同的返回结构，对接体验会非常割裂。另外统一封装后加全局异常处理也方便，业务异常直接抛，由全局异常处理器转成 Result 返回，Controller 里不会出现一堆 try-catch。

3.2 JWT 登录认证与权限拦截

登录认证我选了 JWT（JSON Web Token）方案，而不是传统的 Session。核心区别在于：Session 是服务端存储，JWT 是无状态的自包含令牌。使用 Spring Boot + Spring Security 实现完整的 OAuth2 有点重，所以我这里用的是轻量方案：定义拦截器 + JWT 工具类 + 注解标注。

JWT 生成的 token 结构是三段式——Header.Payload.Signature。我用 JJWT 库来生成和解析，签发时把用户 id、用户名、角色放进 claims，设置过期时间为 24 小时：

public String generateToken(User user) { return Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("username", user.getUsername()) .claim("role", user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

SECRET_KEY是这个方案的命门。我在配置里放的是一个足够长的随机字符串，开发阶段无所谓，上线前一定要换掉默认值。JWT 的安全模型里，签名密钥一旦泄露，任何人都能伪造合法 token，等于系统大门敞开。这一点如果写到部署文档里，会是很加分的安全意识体现。

拦截器我用 HandlerInterceptor 实现，在 preHandle 里从请求头Authorization字段取出 token，解析校验，把解析出的用户信息放到 ThreadLocal 里供后续业务使用。同时配合一个自定义注解@RequireRole，标注在需要特定权限的接口上。比如作业批改接口标注@RequireRole("teacher")，学生调用就直接拒绝。这里用了一个 Spring 的机制——拦截器里拿不到方法上的注解，需要拿到 handler 强转成 HandlerMethod 再获取：

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; // 静态资源直接放行 } HandlerMethod method = (HandlerMethod) handler; RequireRole requireRole = method.getMethodAnnotation(RequireRole.class); // 解析 token、校验角色... }

这个细节很多教程不会提，但你用注解做权限控制时迟早会遇到。我在第一次实现时就是没做 HandlerMethod 判断，结果静态资源请求全部报错，排查了半天才发现是拦截器把非接口的请求也拦了。

3.3 文件上传与资源访问

作业附件、课程资料、用户头像，都涉及文件上传。Spring Boot 接收文件用的是 MultipartFile，配置里要显式设置上传大小限制。我踩过一个典型问题：默认 1MB 上传限制，学生提交一个带视频的作业直接报错。配置如下：

spring: servlet: multipart: max-file-size: 100MB max-request-size: 100MB

文件上传的存储路径我推荐放在项目外部的独立目录，不要存进项目资源目录里。放进 resources 下的文件，每次重新打包部署都会被覆盖，用户传的文件全没了。我的做法是在配置里指定一个绝对路径：

file: upload-dir: /data/platform/uploads/

然后写一个动态映射，把/files/**的请求映射到这个目录：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceMapping("/files/") .setCachePeriod(3600) .addResourceLocations("file:" + uploadDir); } }

注意file:前缀不能丢，少了它 Spring 会认为是 classpath 路径，永远找不到文件。另外这里有个安全细节：文件上传一定要校验扩展名。我在工具类里做了一层白名单过滤，只允许 jpg、png、pdf、doc、docx、zip 等类型，并且不只是看前端传来的文件名后缀，而是用 Java 的 Files.probeContentType 判断实际的 MIME 类型。绕过前端校验很简单，后端不把关等于白设。

4. 前端 Vue 实现与交互细节

4.1 前端工程结构与路由设计

前端我用 Vue CLI 创建工程，采用标准的 src 目录结构：api（接口请求）、assets（静态资源）、components（公共组件）、router（路由）、store（Vuex 状态）、views（页面）、utils（工具）。这样组织的好处是，任何时候新加入一个模块，都知道代码应该放哪个文件夹，不需要到处找。

路由设计上，我用了动态路由权限控制的思路。所谓动态路由，就是登录成功后，根据后端返回的角色信息，动态拼接该角色可见的路由表。管理员看到的是完整后台管理菜单，教师看到的是课程管理、作业管理、学生管理，学生看到的是我的课程、我的作业、在线考试。前端路由表里预先把所有页面的组件都定义好，然后按角色过滤：

const allRoutes = [ { path: '/admin', component: () => import('@/views/Admin/index.vue'), meta: { roles: ['admin'] } }, { path: '/teacher', component: () => import('@/views/Teacher/index.vue'), meta: { roles: ['teacher'] } }, { path: '/student', component: () => import('@/views/Student/index.vue'), meta: { roles: ['student'] } } ]; function filterRoutes(role) { return allRoutes.filter(r => r.meta.roles.includes(role)); }

路由守卫里做登录校验，router.beforeEach里判断：未登录跳转登录页，已登录但访问无权限路由跳转 403。这种"前端路由拦截 + 后端接口拦截"的双层防护是必要的，千万不要只依赖前端判断权限——前端路由守卫只是用户体验层面的保护，真正的安全边界一定在后端接口。我见过有的同学只在前端隐藏了管理按钮，后端接口裸奔，用 Postman 直接调接口就能删数据，这属于硬伤。

4.2 Axios 封装与统一请求处理

前端所有请求我统一走一个封装的 request 模块，基于 axios。封装的核心有两点：请求拦截器自动携带 token，响应拦截器统一处理错误。

// utils/request.js import axios from 'axios'; import { Message } from 'element-ui'; import router from '@/router'; const service = axios.create({ baseURL: process.env.VUE_APP_BASE_URL, timeout: 10000 }); // 请求拦截器：带上 token service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); // 响应拦截器：统一处理错误 service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { Message.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res.data; }, error => { if (error.response && error.response.status === 401) { Message.error('登录已过期，请重新登录'); localStorage.removeItem('token'); router.push('/login'); } else { Message.error('网络异常，请稍后重试'); } return Promise.reject(error); } );

这个封装投入产出比非常高。一处封装，全项目受益。尤其 401 统一处理这个逻辑，如果不放在拦截器里，每个页面都要自己写一遍"判断登录过期→清除 token→跳转登录页"，又容易漏又容易写出重复代码。

还有一个实战经验：接口的 baseURL 用环境变量区分开发和生产。开发阶段前端跑 8080 端口，后端跑 8081，接口请求要经过 Vue 的 devServer 代理转发，避免跨域。生产阶段前端打包成静态文件放在 Nginx 里，接口请求走 Nginx 的反向代理。两种情况 baseURL 不一样，用.env.development和.env.production分开配置，打包时 Vue CLI 会自动加载对应环境的变量。

4.3 在线考试与作业提价的交互实现

我把在线考试的页面单独拎出来说，因为它是整个系统里交互最复杂的模块。学生进入考试后，页面布局是：左侧题目列表（显示题号和作答状态），中间是答题区，顶部是倒计时。需要用定时器同步考试剩余时间：

startTimer() { this.timer = setInterval(() => { this.remainingSeconds--; if (this.remainingSeconds <= 0) { this.autoSubmit(); // 自动交卷 } }, 1000); }

倒计时这里的坑在于：时间要以服务端下发的考试截止时间为准，而不是前端本地时间。学生完全可以改自己电脑的系统时间来延长考试。我在后端交卷接口做了一道校验，前端也做一道视觉提示，双保险。

作答过程中，每答完一题就把答案存进 Vuex 或者本地临时对象里，同时同步更新左侧题目的状态标识。学生点击交卷时，前端先检查是否还有题目未作答，给出确认提示，然后调用交卷接口。交互逻辑看起来简单，但要把"暂存答案、状态同步、倒计时刷新、防重复提交"几件事同时做好，代码量不小。我的习惯是：把考试页面的状态管理独立出来，用 Vuex 的 module 单独管理，避免页面组件之间共享状态出现混乱。

作业提价的交互相对简单：学生上传文件，校验文件大小和格式，然后展示传进度（用了 Element UI 的 Upload 组件的 progress 回调）。这里有一个体验细节：上传成功后一定要把服务端返回的文件地址保存到表单数据里，再提交表单，而不是上传完成就直接提交。因为用户可能先上传附件、再改标题、再补充说明，最后才点提交。上传和提交是两个动作，要分开处理。

5. 部署流程与上线配置

5.1 环境准备与数据库初始化

部署我之前一直推荐用 Linux 服务器（CentOS 或 Ubuntu 都行），因为线上环境和本机 Windows/Mac 环境差异越小越好，很多问题都是"本地好好的，一到服务器就挂"。需要安装的东西按顺序来：JDK 1.8、MySQL 5.7/8.0、Redis、Nginx、Maven（后端打包用）。

数据库初始化这块，最规范的做法是用源码里提供的 SQL 脚本。拿到的项目一般会带一个sxl_platform.sql文件（数据库脚本名称通常是项目名），在 MySQL 里执行：

mysql -u root -p < /data/sxl_platform.sql

执行后检查三件事：表是否建全、初始管理员账号是否写入、测试数据是否导入。如果脚本里没有初始管理员账号，一定要自己手动 Insert 一条，不然系统装好连后台都登不进去。我在一台新服务器上部署时就遇到过这种情况，SQL 脚本里居然忘了写管理员初始密码，登录接口一直报用户不存在，排查了半天才想到看表数据。

5.2 后端打包与配置要点

后端的打包产物是 Spring Boot 的可执行 Jar 包。打包前要改application.yml里的环境配置，重点检查数据库连接、Redis 地址、文件上传路径这三项。开发环境用的 localhost 在服务器上肯定不行，要改成服务器的实际地址，端口也要注意别被占用。打包命令：

mvn clean package -DskipTests

如果用的是 Maven 私服或者默认中央仓库，第一次打包可能会因为下载依赖耗时较长，这是正常的。打包完成后 Jar 包在 target 目录下。启动方式我推荐用 nohup 让进程在后台运行：

nohup java -jar sxl-platform.jar --spring.profiles.active=prod > /data/logs/platform.log 2>&1 &

这个命令有两个细节值得说明。第一，--spring.profiles.active=prod指定了 prod 配置文件，不同的环境用不同的 profile，避免手动改配置出错。第二，日志重定向到指定的 log 文件而不是直接丢弃，不然之后排查问题连日志都找不到。启动后用tail -f盯一下日志，看到Started Application in x.xxx seconds就说明启动成功了。

后端启动在服务器的 8081 端口，为了安全，我设置了防火墙只放行需要的端口：80/443 给 Nginx，8081 只对内网开放。如果部署在云服务器上，安全组的入站规则也要对应配置。这一步是很多教程不写但生产环境必须做的——后端端口不对公网直接暴露，减少被扫描攻击的面。

5.3 前端构建与 Nginx 部署

前端没有编译安装过程，Vue 项目构建完就是一批静态文件。在项目根目录执行：

npm install npm run build

构建产物在dist目录。把整个 dist 目录传到服务器，比如放到/data/www/sxl-platform/dist，然后配置 Nginx 站点。核心配置如下：

server { listen 80; server_name your-domain.com; root /data/www/sxl-platform/dist; index index.html; # 前端路由是 history 模式，必须做 try_files，否则刷新页面 404 location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传文件访问 location /files/ { alias /data/platform/uploads/; } }

这份配置里最关键的，也是访问量最高的问题，就是try_files $uri $uri/ /index.html;这一行。Vue Router 默认用 history 模式，页面路径是真实的 URL 而不是带#的 hash 路由。如果不配 try_files，用户登录后点击刷新，Nginx 会去磁盘找/student/course这个路径对应的文件，找不到就返回 404。配了 try_files 之后，所有前端路由都回退到 index.html，由 Vue Router 自己在内存里匹配组件。

还有一个坑：后端接口代理的地址不要带端口暴露给前端。如果前端直接请求http://服务器IP:8081/api/login，浏览器会跨域并触发 CORS，而且端口暴露会降低安全性。用 Nginx 代理到 8081 服务，不改变客户端看到的请求地址，一举两得。部署完成后再检查一下前端构建环境变量VUE_APP_BASE_URL，生产环境需要是/api这样的相对路径或同域的完整路径。

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

6.1 前后端联调期的高频故障

联调阶段的问题，九成以上集中在三个地方：跨域、token、数据格式。

跨域报错是新手遇到最多的。现象是浏览器控制台报CORS policy错误，接口状态码是 0 或者网络层直接失败。根治方案不是在前端随便加代理，而是分环境处理：开发环境用 Vue CLI 的 devServer.proxy 把/api转发到后端的 8081，生产环境用 Nginx 反向代理解决。如果后端接口确实需要允许跨域，最稳妥的是用 CorsFilter 显式配置允许的域名，不要用通配符*一放到底，那等于把接口开放给所有网站调用。

token 问题典型的是"登录成功了，但一访问业务接口就 401"。排查顺序：先看浏览器 Application 面板里 localStorage 有没有 token；再看请求头 Network 面板 Authorization 有没有带上；再看后端拦截器是否解析成功。我自己遇到过一个隐蔽问题：后端密钥和签发密钥不一致——本地测试用的一套 SECRET_KEY，部署时改了 application.yml 里的值，但旧 token 还没过期，导致一段时间内所有人访问都异常。解决办法是签发校验共用一个配置源，部署时同步清掉旧 token 或让用户重新登录。

数据格式问题最常见的是日期格式前后端不一致。后端返回2024-06-25T14:30:00，前端 Element UI 的日期组件需要2024-06-25 14:30:00，展示出来就乱码。我直接在全局配置里统一了日期序列化格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

时区也要显式指定 GMT+8，不然部署到海外时间线的服务器，数据库里存的时间会差 8 小时，成绩发布和考试截止时间全乱套。

6.2 部署阶段的问题排查

部署到服务器后出现的问题，往往比本地更诡异，因为环境差异放大了。我整理几个高频场景。

端口被占用：java -jar启动报Port 8081 was already in use。先netstat -tlnp | grep 8081看是什么进程占着，如果是残留的旧服务，kill -9之后重新启动。这个场景在反复迭代部署时尤其常见——旧的 Jar 进程没有杀掉，新进程起不来。

MySQL 连接失败：报Communications link failure。先确认 MySQL 服务是否启动（systemctl status mysqld），再确认账号权限——MySQL 8.0 默认的 root 账号可能只允许 localhost 连接，远程连接需要单独授权。还有一个隐蔽点：云服务商的安全组规则没放行 3306 端口，即使本机防火墙关了，安全组这层也会拦截。

Redis 连不上：报connection refused。检查 Redis 配置里的bind和protected-mode，默认配置下 Redis 仅监听本地回环地址，外部程序根本连不上。如果确实要开放，建议设置密码认证，不要裸奔。

前端页面白屏：大概率是构建产物问题。先看浏览器 console 报错，常见的是部署路径和 Vue 的 publicPath 不一致。如果你的前端不是放在域名根目录而是放在子路径，需要在vue.config.js里配置publicPath: './'或者指定子路径，重新构建再部署。

6.3 答辩与文档准备的几个提醒

虽然这篇主要聊技术，但这个项目挂在"源码文档部署文档代码讲解"的语境下，答辩环节还是值得提两句，因为我在帮人准备时发现很多技术做得好的人死在表达上。有几个特别容易被问、必须提前准备的问题：

第一个问题："你的系统安全性怎么保障？"回答要落到具体手段上：密码加盐存储、JWT 过期校验、拦截器做接口权限控制、上传文件类型白名单、SQL 注入用 MyBatis-Plus 的参数占位符规避。不要泛泛而谈"我们很注重安全"，要有代码层面的证据。

第二个问题："为什么选 MyBatis-Plus？"说实话实说：单表操作效率高、内置分页插件、避免手写大量重复 SQL。同时可以补充一句：复杂的多表关联场景仍然保留 XML 方式手写 SQL，兼顾了两种场景。这比背一个"MyBatis-Plus 是一个优秀的持久层框架"这种教科书答案生动得多。

第三个问题："如果学生量翻十倍，系统哪里会先扛不住？"这问题考验的是瓶颈分析能力。诚实的回答是：单点部署下，数据库连接池和文件存储会成为最先到瓶颈的地方。然后给出改进思路：数据库读写分离、Redis 缓存热点数据、对象存储替代本地磁盘、前端加 CDN。即使这些方案没真正落地，能说清"哪里会挂、怎么优化"，就已经超出很多同龄人的水平了。

文档方面，部署文档不要只写"下一步、下一步"，要把每一步的命令、可能出现的问题、对应的解决方案都写进去。一份好的部署文档的标准是：一个完全不懂这个项目的人，照着文档也能在一台干净服务器上把系统跑起来。源码注释也是同样的逻辑——核心代码块一定要写"为什么这么写"，而不只是"这是什么"。我后来再看自己写的注释，发现当时写的"遍历列表"这种废话注释毫无价值，真正有用的是"这里必须深拷贝，因为原数组后续会被修改"这种揭示设计意图的注释。

写在最后的一点体会

做这类完整项目，我最大的感受是：代码量反而不是最大的成本，最大的是排查问题的经验。上面写的这些问题——跨域、端口占用、时区错乱、上传路径丢失、刷新 404——每一个都是我或我协助的同学真实踩过的。如果你正在做类似的系统，不要怕报错，报错反而是好事，它逼着你把原理搞明白。建议按"模块-接口-部署"三个阶段逐个击破，不要想着一次性把系统从头到尾写完美再测试，那是不现实的。先让最小闭环跑通，再逐步加功能，这是效率最高的路径。最后再多说一句：拿到任何带源码带文档的学习平台系统，第一件事别急着跑起来，先把它拆开看结构，搞清楚每个文件是干什么的，再动手改代码做二次开发。磨刀不误砍柴工。