1. 技术选型：为什么"SpringBoot+Vue"是毕设项目的最优解
先交代一下背景。这个项目是一个典型的Java Web毕业设计——游戏管理平台，前端展示游戏信息、用户注册登录、后台管理游戏分类、上架下架、订单记录等等。这类项目在毕设选题里出现频率极高，但很多人一上来就纠结技术栈：有人用JSP+Servlet，有人用SSH，还有人非要自己写个框架。我个人的建议非常明确：如果不想给自己挖坑，SpringBoot+Vue就是当前阶段最稳妥、最省心、也最能拿得出手的组合。
1.1 后端选SpringBoot的核心原因
SpringBoot最大的价值不是"新"，而是它把Spring生态里那些繁琐的配置全部自动化了。以前用SpringMVC写一个HelloWorld，光配置web.xml、spring-mvc.xml就能折腾半天，现在SpringBoot一个启动类加上几个注解就搞定。对于毕设来说，时间就那么多，把精力花在业务逻辑上比花在配置文件上有价值得多。
这个游戏管理平台的后端需求其实非常清晰：
- 用户模块：注册、登录、个人信息维护
- 游戏模块：游戏列表、分类、详情、搜索
- 管理模块：后台CRUD、上架下架、数据统计
- 订单模块：用户购买、订单查询、状态流转
这些需求用SpringBoot实现，学习成本低，社区资料多，出了任何问题都能搜到解决方案。相比SSH那种老古董，SpringBoot的自动配置和起步依赖能帮你省掉至少一周的搭建时间。
1.2 前端选Vue的现实考量
前端部分，Vue在这个场景下几乎是唯一推荐的选项。为什么不是React？不是Angular？不是说它们不好，而是对于大多数Java方向的学生来说，Vue的学习曲线最平缓，中文文档和教程最丰富，而且Vue的模板语法更接近传统的HTML思维，上手非常快。
这个项目的前端主要是管理后台和门户页面，Vue + Element UI（或Element Plus）的组合能非常高效地完成布局、表单、表格、弹窗等常见界面。对于毕设来说，界面美观是一方面，更重要的是能用可复现的方式快速实现功能，Vue的组件化开发在这方面优势明显。
1.3 游戏管理平台的具体业务边界
在做任何设计之前，先想清楚这个"游戏管理平台"到底要管什么。我从功能角度拆解一下：
- 前台门户：游戏列表展示（分页、分类筛选）、游戏详情（封面、价格、简介、截图）、用户登录注册
- 用户中心：个人信息、我的订单、收藏列表（如果有）
- 后台管理：游戏管理（新增、编辑、删除、上架/下架）、分类管理、订单管理、用户管理
- 公共模块：登录鉴权、数据统计、文件上传（游戏封面等）
把这些业务边界确定下来，数据库设计和接口设计就有据可依了。这也是整个项目最重要的第一步——不要上来就写代码，先把业务理清楚。
2. 数据库设计：SQL脚本背后的一张表关系网
数据库设计是这种项目最容易翻车的地方。很多同学上来就建表，结果表之间关系混乱，后面写接口的时候各种牵强。我在这个项目中花了一整块时间来设计表结构，基本原则是：满足业务需求、保持适度冗余、表数量控制在8-12张左右，这样既显得项目有分量，又不至于把自己累死。
2.1 核心表结构一览
这个游戏管理平台我设计了以下核心表：
| 表名 | 说明 | 关键字段 |
|---|---|---|
user | 用户表 | id, username, password, nickname, avatar, role, create_time |
game | 游戏表 | id, category_id, name, cover, price, description, status, sales, create_time |
category | 游戏分类表 | id, name, sort |
order | 订单表 | id, order_no, user_id, total_amount, status, create_time |
order_item | 订单明细表 | id, order_id, game_id, game_name, price, quantity |
cart | 购物车表 | id, user_id, game_id, quantity |
carousel | 轮播图表 | id, image_url, game_id, sort |
admin_log | 操作日志表 | id, admin_id, action, detail, create_time |
2.2 字段类型和外键策略的选择
一个关键的决策点：金额字段用什么类型？很多初学者用double或float，这是大忌。浮点数在Java和MySQL中都存在精度问题，购买游戏、统计报表的时候会出现0.9999999这种尴尬结果。我采用的是DECIMAL(10,2)，前后端都按字符串或精确数值处理，彻底规避精度问题。
外键的设计上，我倾向于"保留逻辑外键、去掉物理外键"。什么意思？就是在Java代码层通过字段关联（比如game.category_id），但不在MySQL里强制创建FOREIGN KEY约束。原因有两个：
- 毕设项目中数据量不大，物理外键带来的数据一致性保障收益有限
- 物理外键会严重影响后续的数据操作便捷性，比如删除分类时需要先处理该分类下的所有游戏，物理外键会拦着不让你删，逻辑外键则可以通过代码控制
当然，如果你想让数据库看起来更"正规"，也可以加上物理外键。只是我个人经验是：毕设项目用逻辑外键，开发效率更高，答辩时也更容易解释清楚。
2.3 SQL脚本的编写与种子数据
SQL脚本不是你手敲的，而是要保证"可重复执行"。我的做法是：
-- 初始化分类数据 INSERT INTO category (id, name, sort) VALUES (1, '动作冒险', 1), (2, '角色扮演', 2), (3, '休闲益智', 3), (4, '竞速体育', 4), (5, '策略战棋', 5);这里有个小细节：所有初始化数据都带明确的主键id，而不是依赖自增。因为后续如果要在种子数据中建立关联（比如轮播图指向某个游戏），有确定id才好引用。
种子数据要"够用但不乱"。我一般会准备：
- 5-8个分类
- 30-50个游戏记录，封面图用占位图URL
- 2个测试账号（一个普通用户、一个管理员）
- 若干条订单数据（用来展示统计图表）
不够的时侯我就在SQL里直接补，尽量让登录后的首页、游戏列表页、后台统计页看起来不是空荡荡的，这对接下来的功能演示和答辩非常关键。
3. 后端工程实践：让代码经得起答辩追问
后端是整个项目的重头戏。这一部分如果说得好听点，叫"工程实践"，说得接地气一点，就是"怎么把代码写得不像是应付事的"。SpringBoot项目结构如果不讲究，后面写业务的时候哭都来不及。
3.1 分层架构与包结构设计
我采用的包结构如下：
com.example.gameplatform ├── controller // 接口层 ├── service // 业务层 │ └── impl ├── mapper // 数据访问层（MyBatis-Plus） ├── entity // 实体类 ├── dto // 数据传输对象 ├── vo // 视图返回对象 ├── common // 通用结果封装、常量、异常处理 ├── config // 配置类（跨域、拦截器、Swagger等） └── utils // 工具类（JWT、MD5等）为什么要分这么多层？不是装样子，而是每层解决不同的问题。Controller只负责接收参数和返回结果，Service专注业务逻辑，Mapper只做数据持久化。这样分工，答辩时老师问"你的项目是怎么分层的"，你能讲得清清楚楚；问"为什么用户注册逻辑写在Service而不是Controller"，你也能答得明明白白。
3.2 统一返回结果与全局异常处理
前端对接时最怕的情况是：每个接口返回的数据结构都不一样。有的接口返回{code: 200, data: {...}}，有的返回{success: true, data: ...}，前端每次都要特殊处理，各种NPE。解决方式很简单——全局统一返回结果类。
我在项目中定义了Result<T>：
@Data public class Result<T> { private Integer code; // 200成功，500失败 private String message; // 提示信息 private T data; // 数据体 }然后配合@RestControllerAdvice做全局异常处理。不管是业务异常（比如"库存不足"）还是系统异常（比如空指针），都能以统一的响应格式返回给前端。这个设计几乎是所有企业级SpringBoot项目的标配，放毕设里绝对是加分项。
3.3 登录鉴权：JWT的实现细节
登录功能谁都会写，但写得好不好看就是另一回事了。比较low的做法是登录成功后把用户id存在Session里，每次请求用Session判断。这个方案在这个前后端分离项目中行不通，因为前端Vue和后端SpringBoot往往是分开部署的，Session在不同域之间不共享。
我采用的是JWT（JSON Web Token）方案。用户登录成功后，后端签发一个携带用户id和角色信息的Token，前端存储后在每次请求时放在请求头的Authorization字段。后端通过拦截器统一校验Token的合法性，并从中取出用户信息。
关键代码逻辑：
@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BusinessException("未登录或登录已过期"); } // 校验签名，解析出userId和role Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("userRole", claims.get("role")); return true; } }这里要特别提醒一个坑：JWT不要放敏感信息。当年token里放了用户的明文密码，虽然JWT默认不是加密的，但这种做法不仅不安全，答辩时被老师问到还会很尴尬。Token里只放userId和角色就够了，需要用户信息时再去数据库查。
鉴权的另一个重点是权限控制。这个平台有普通用户和管理员两种角色，管理端接口需要校验角色。我的做法是在拦截器里统一处理：
@RequestMapping("/admin/game/save") public Result<?> save(@RequestBody Game game, HttpServletRequest request) { String role = (String) request.getAttribute("userRole"); if (!"ADMIN".equals(role)) { throw new BusinessException("无权限操作"); } // 保存逻辑 }虽然更优雅的方案是配合Spring Security或自定义注解做权限管理，但毕设项目的复杂度用这种"拦截器+角色判断"的方式已经足够，而且逻辑清晰，答辩时容易讲明白。
3.4 接口文档：Swagger/Knife4j的配置与价值
标题里特别写了"接口文档"，这说明文档是项目交付的一部分。手写Word接口文档不仅费时，而且代码一改就不同步了。我的选择是集成Knife4j（Swagger的增强版），接口写完之后自动生成在线文档。
话不多说，关键配置如下：
<dependency> <groupId>com.github.xiaoymin</groupId> <artifactId>knife4j-spring-boot-starter</artifactId> <version>3.0.3</version> </dependency>然后在Controller上加Swagger注解，就可以通过http://localhost:8080/doc.html查看接口文档，还带调试功能，比Postman还方便。
这里要特别强调一下：接口文档的意义不只是给老师看的，更是给你自己看的。前后端联调时，前端同学或你自己写的Vue代码要对接接口，没有文档就得回头看代码，效率极其低下。有了Swagger之后，请求参数、返回结构一目了然，开发效率直接翻倍。
4. 前端Vue实现：从登录页到游戏管理后台
前端部分的工作量其实不比后端少，但很多人低估了它的难度。我见过太多人把Vue代码写成"HTML+JS缝合怪"——没有组件化、没有路由管理、没有状态管理，代码堆在一起，能运行但一团糟。这种代码拿来毕设，答辩时老师一眼就能看出技术含量不高。
4.1 项目结构与路由设计
Vue项目的结构我建议按模块划分：
src ├── api // 接口请求封装 ├── assets // 静态资源 ├── components // 公共组件 ├── router // 路由配置 ├── views // 页面组件 │ ├── Home.vue // 首页（游戏列表） │ ├── Login.vue // 登录 │ ├── Register.vue // 注册 │ ├── GameDetail.vue // 游戏详情 │ ├── Cart.vue // 购物车 │ ├── Order.vue // 订单列表 │ └── admin // 后台管理 │ ├── AdminLayout.vue │ ├── GameManage.vue │ ├── CategoryManage.vue │ ├── OrderManage.vue │ └── UserManage.vue路由配置上要注意路由守卫。未登录用户无法直接打开后台管理页面，管理员才能访问admin相关的路由。Vue Router的beforeEach钩子里做判断：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path.startsWith('/admin') && !token) { next({ path: '/login', query: { redirect: to.fullPath } }) } else { next() } })这个地方有个细节很值得注意：从后端拿到的不是完整个人信息，而是token。Vue前端拿到token后，调用/api/user/info获取昵称、头像、角色等信息，存到Vuex或Pinia中。如果路由守卫里只判断"有没有token"而不判断"角色是不是管理员"，那普通用户也能访问后台页面，这就是一个典型的权限漏洞。
4.2 Axios封装与请求拦截器
前端请求不能每个页面都写一遍axios.get(...)，太low了。我的做法是统一封装一个request.js：
import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动带上token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.message || '网络异常') return Promise.reject(error) } ) export default request这套封装的妙处在于：所有页面只需要关心业务数据，不需要重复处理"token过期""请求失败"这些交叉关注点。这就是Axios拦截器的价值。
4.3 游戏管理模块：典型的CRUD页面写法
游戏管理是后台最核心的模块，也是最能体现代码水平的部分。我以"游戏列表"为例，说明一下完整实现思路。
页面效果大概是这样：顶部是筛选区（根据游戏名称、状态），下方是表格，操作栏有新增、编辑、上架/下架、删除按钮。
<template> <div class="game-manage"> <el-card> <div class="search-bar"> <el-input v-model="queryParams.name" placeholder="游戏名称" style="width: 200px" /> <el-select v-model="queryParams.status" placeholder="状态"> <el-option label="全部" value="" /> <el-option label="已上架" value="1" /> <el-option label="已下架" value="0" /> </el-select> <el-button type="primary" @click="loadList">查询</el-button> <el-button type="success" @click="openDialog()">新增游戏</el-button> </div> <el-table :data="tableData" border stripe> <el-table-column prop="name" label="游戏名" /> <el-table-column prop="categoryName" label="分类" /> <el-table-column prop="price" label="价格" /> <el-table-column prop="status" label="状态"> <template #default="{ row }"> <el-tag :type="row.status === 1 ? 'success' : 'info'"> {{ row.status === 1 ? '已上架' : '已下架' }} </el-tag> </template> </el-table-column> <el-table-column label="操作"> <template #default="{ row }"> <el-button size="small" @click="openDialog(row)">编辑</el-button> <el-button size="small" type="warning" @click="toggleStatus(row)"> {{ row.status === 1 ? '下架' : '上架' }} </el-button> <el-button size="small" type="danger" @click="deleteGame(row)">删除</el-button> </template> </el-table-column> </el-table> <el-pagination v-model:current-page="queryParams.pageNum" :page-size="queryParams.pageSize" :total="total" layout="total, prev, pager, next" @current-change="loadList" /> </el-card> <!-- 新增/编辑对话框 --> <el-dialog v-model="dialogVisible" :title="form.id ? '编辑游戏' : '新增游戏'" width="500px"> <el-form :model="form" label-width="80px"> <el-form-item label="游戏名称"> <el-input v-model="form.name" /> </el-form-item> <el-form-item label="分类"> <el-select v-model="form.categoryId"> <el-option v-for="item in categoryList" :key="item.id" :label="item.name" :value="item.id" /> </el-select> </el-form-item> <el-form-item label="价格"> <el-input-number v-model="form.price" :min="0" :precision="2" /> </el-form-item> <el-form-item label="简介"> <el-input v-model="form.description" type="textarea" /> </el-form-item> <el-form-item label="封面图"> <el-upload :action="uploadUrl" :headers="uploadHeaders" :on-success="handleUploadSuccess" > <el-button>上传图片</el-button> </el-upload> </el-form-item> </el-form> <template #footer> <el-button @click="dialogVisible = false">取消</el-button> <el-button type="primary" @click="submitForm">保存</el-button> </template> </el-dialog> </div> </template>这是典型的管理后台页面，所有模块（分类管理、订单管理、用户管理）都可以复刻这套模式。需要注意的是分页参数的传递——pageNum、pageSize要与后端接口的Page<T>分页对象对接好。
4.4 前端状态管理与用户信息持久化
游戏管理平台的前端状态管理我用的是Pinia（Vue3）或Vuex（Vue2），主要存三类信息：
- 用户信息：
userInfo，包括昵称、头像、角色 - 登录状态：
isLoggedIn，页面刷新后从localStorage恢复 - 购物车数量：
cartCount，用于首页导航栏红点显示
要注意的是：页面刷新后Vuex/Pinia中的数据会丢失，所以要在store的初始化逻辑里从localStorage读取已保存的状态。这个细节处理不好，就会出现"刷新后导航栏上的用户名没了"的尴尬问题。
5. 前后端联调与部署：最容易翻车的环节
功能代码都写完了，接下来就是联调和部署。这个环节踩坑概率极高，而且基本都是集成类问题。不是单个模块不工作，而是模块之间"接不上"。这里把我踩过的坑都列出来。
5.1 跨域问题：前后端分离的经典拦路虎
本地联调时，前端跑在http://localhost:5173（Vite默认端口），后端跑在http://localhost:8080，这就不满足浏览器的同源策略，所以必须先解决跨域。
解决方案有三种：
方案一：后端加CORS配置（全局处理）
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }方案二：前端代理（Vite配置）
// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })方案三：Nginx反向代理（生产环境的推荐做法）
location /api/ { proxy_pass http://localhost:8080/; }我的建议是：本地开发用方案二（前端代理），部署上线用方案三（Nginx代理），CORS配置做兜底。三者不冲突，但要注意配置正确。
注意：方案一里面的
allowedOriginPatterns("*")配allowCredentials(true)时，在SpringBoot老版本中不允许直接配*，需要指定具体域名或用allowedOriginPatterns，这是一个很容易踩的版本兼容坑。
5.2 将Vue打包后放进SpringBoot：两种主流方案
部署方式上，有两种主流选择：
方案A：前后端分体部署
前端打包生成dist目录，部署到Nginx，后端SpringBoot以jar包形式运行，Nginx配置代理转发。这种方式好处是前后端独立升级，缺点是部署环境需要同时管理两个服务。
方案B：前端文件放进SpringBoot的static目录
将Vue的dist目录内容拷贝到src/main/resources/static/下，SpringBoot的嵌入Tomcat直接托管静态文件。这种方式部署简单，一个jar包搞定一切。
方案B是我在这个项目中采用的。但这里有一个大坑：Vue路由使用history模式时，刷新页面会出现404！原因很简单，前端路由是/game/1这种路径，刷新时请求发给了后端，后端没有对应的Controller或静态资源映射，就返回404了。
解决方式是配置一个路由兜底转发：
@Controller public class PageForwardController { @RequestMapping(value = {"/", "/game/**", "/admin/**", "/login", "/register"}) public String forward() { return "forward:/index.html"; } }这样所有前端路由的请求都会转发到index.html，由Vue Router接管并渲染正确的页面。如果不做这个配置，刷新就404，绝对是你答辩演示时的噩梦。
5.3 数据库版本与连接配置
部署时最常见的另一个问题是数据库连不上。SpringBoot的application.yml配置如下：
spring: datasource: url: jdbc:mysql://localhost:3306/game_platform?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver几个值得注意的细节：
serverTimezone=Asia/Shanghai必须加，否则MySQL 8.x时差问题会让你所有时间字段都不对useSSL=false是避免SSL握手警告- 高版本的MySQL用
com.mysql.cj.jdbc.Driver，老版本才是com.mysql.jdbc.Driver，写错直接启动报错
另外，SQL脚本执行时要注意MySQL版本兼容性。如果用的是MySQL 8.0，建表语句中不要把rank、order等保留字作为字段名，否则会报语法错误。我在设计订单表时特意用order_no和game_name来避开保留字问题。
5.4 部署后的经典问题排查
把项目部署到服务器上之后，我用一个Checklist来排查问题，分享一下：
| 现象 | 排查方向 |
|---|---|
| 前端页面打不开 | 静态资源路径错误？Nginx配置？jar包中的static目录是否正确？ |
| 登录报跨域错误 | 后端CORS配置是否生效？前端代理路径是否匹配？ |
| 接口返回404 | Controller的@RequestMapping路径是否与前端请求一致？ |
| 数据库中文乱码 | 数据库连接URL中characterEncoding=utf-8是否配置？数据库本身的字符集是否是utf8mb4？ |
| 上传图片预览不了 | 文件上传路径是否可写？静态资源映射是否配置？ |
| 刷新页面404 | Vue路由history模式+SprintBoot兜底转发是否配置？ |
6. 复盘与答辩准备：一个能拿"优秀"的毕设项目应该有什么
项目做完了，代码能跑、功能齐全，这只是底线。想拿高分甚至"优秀"，还需要在细节上多下功夫。这节说说我在答辩和复盘时的经验和教训。
6.1 代码脏乱差的常见扣分点
答辩时老师看代码比你想象中仔细，但也不是逐行阅读，他们主要关注几个地方：
- 包结构是否清晰：杂乱无章的包名和类是第一印象，非常影响评分
- 是否有重复代码：比如多个Controller里重复写分页逻辑，这是明显的代码质量问题
- 密码是否明文存库：密码用MD5或BCrypt加密是最基本的底线
- SQL注入风险：用了MyBatis的
${}拼接字符串，一查一个准，必须用#{} - 异常处理是否得当：Controller里大段大段的
try-catch吃掉异常还打印e.printStackTrace()，观感极差
6.2 答辩时必被问到的几个技术问题
作为项目作者，你要能回答"为什么"的问题。我整理了一些高频问题供参考：
"为什么选MyBatis-Plus而不直接写SQL？"
MyBatis-Plus提供了丰富的CRUD封装，单表操作完全不需要手写SQL。但复杂查询（如条件分页、联表查询）我仍然通过自定义Mapper方法实现。这样既保证开发效率，也保留手写SQL的灵活性。
"JWT和Session鉴权有什么区别？为什么选JWT？"
核心区别在于状态管理。Session需要服务端保存会话信息，扩展时要做会话共享；JWT是无状态的，服务端只需要验证签名，天然适合前后端分离和分布式部署。但JWT也有缺点——无法主动失效，所以在权限变更或注销时处理需要额外考虑。
"用户的密码你是如何存储的？"
不能明文存库，我使用的是BCryptPasswordEncoder，它是一种自适应hash算法，加盐且可以调节计算强度。同样的密码每次加密结果不同，抗暴力破解能力强。
"如果游戏下架了，用户购物车里的游戏还能下单吗？"
这个问题非常考验细节。我的处理是：提交订单时重新校验购物车中每个游戏的状态和价格，如果有游戏已下架或价格变动，提示用户刷新购物车。校验逻辑不放在前端，而是放在后端Service层，防止绕过前端直接调用接口下单。
6.3 从"能跑"到"好看"：加分项经验
如果时间和精力允许，这几个小功能能明显提升项目档次：
数据可视化：使用ECharts画一个后台数据看板，统计游戏销量Top10、订单趋势图。这个在答辩时展示效果极好，而且ECharts是纯前端引入，难度不大。
文件上传与静态资源映射：游戏封面图上传后能正常回显。很多人做上传只做了"上传成功"就完了，没有处理显示逻辑。要让上传的图片能通过URL访问，需要配置静态资源映射。
操作日志：管理员每次操作（上架、下架、删除）都记录到日志表。这是一个很小的功能，但能体现"系统设计思维"。
表单校验：前端和后端都要做参数校验，前端用Element Plus的表单规则，后端用
@Validated注解。只做前端校验的人，会被老师一句话问死："我不通过你的前端页面，直接调接口提交非法参数怎么办？"
6.4 我自己的复盘与经验总结
做这个游戏管理平台项目，我最深的感触是：技术栈本身不难，难点在于把细节做到位。很多人毕设翻车不是因为技术不行，而是因为以下三个问题没处理好：
第一，重构恐惧症。写着写着发现表结构不合理、接口路径不统一、前端组件复用性差，但不敢动——怕一改全崩。我的经验是：如果要改动表结构或核心接口，越早改越好，拖到最后一天就是改一个地方坏三个地方。我在设计初始阶段就把表结构反复推演了三遍才动手建表。
第二，联调经验不足。前后端分离项目最消耗时间的不是写代码，而是联调。前端和后端对接口字段理解不一致，就能卡一下午。解决办法是：前后端同时参考Swagger接口文档，以文档为准；遇到参数不匹配时不要互相“猜”，直接看一下请求和返回的实际JSON。
第三，部署环节重视不够。很多同学在本地开发运行好好的，打包部署到服务器就各种问题。我建议最晚在答辩前一周就开始部署演练，把所有环境问题、配置问题全部暴露出来。尤其要检查打包后的jar包中是否有前端dist目录、数据库脚本在干净环境中能否正常完成初始化。
这个项目的完整流程走下来，实质上覆盖了一个企业级Java Web项目从0到1的全过程。对于找工作的人来说，能把这个项目讲透——从数据库设计到后端分层，从JWT鉴权到前端路由守卫，从本地联调到服务器部署——在面试中至少可以证明你具备独立完成一个完整Web系统的能力。对于准备答辩的人来说，提前把每个模块的"为什么"想清楚，比你把代码背下来更管用。
