1. 技术选型为什么SpringBootVue是毕设项目的最优解先交代一下背景。这个项目是一个典型的Java Web毕业设计——游戏管理平台前端展示游戏信息、用户注册登录、后台管理游戏分类、上架下架、订单记录等等。这类项目在毕设选题里出现频率极高但很多人一上来就纠结技术栈有人用JSPServlet有人用SSH还有人非要自己写个框架。我个人的建议非常明确如果不想给自己挖坑SpringBootVue就是当前阶段最稳妥、最省心、也最能拿得出手的组合。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_timegame游戏表id, category_id, name, cover, price, description, status, sales, create_timecategory游戏分类表id, name, sortorder订单表id, order_no, user_id, total_amount, status, create_timeorder_item订单明细表id, order_id, game_id, game_name, price, quantitycart购物车表id, user_id, game_id, quantitycarousel轮播图表id, image_url, game_id, sortadmin_log操作日志表id, admin_id, action, detail, create_time2.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个游戏记录封面图用占位图URL2个测试账号一个普通用户、一个管理员若干条订单数据用来展示统计图表不够的时侯我就在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。解决方式很简单——全局统一返回结果类。我在项目中定义了ResultTData public class ResultT { private Integer code; // 200成功500失败 private String message; // 提示信息 private T data; // 数据体 }然后配合RestControllerAdvice做全局异常处理。不管是业务异常比如库存不足还是系统异常比如空指针都能以统一的响应格式返回给前端。这个设计几乎是所有企业级SpringBoot项目的标配放毕设里绝对是加分项。3.3 登录鉴权JWT的实现细节登录功能谁都会写但写得好不好看就是另一回事了。比较low的做法是登录成功后把用户id存在Session里每次请求用Session判断。这个方案在这个前后端分离项目中行不通因为前端Vue和后端SpringBoot往往是分开部署的Session在不同域之间不共享。我采用的是JWTJSON 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接口文档不仅费时而且代码一改就不同步了。我的选择是集成Knife4jSwagger的增强版接口写完之后自动生成在线文档。话不多说关键配置如下dependency groupIdcom.github.xiaoymin/groupId artifactIdknife4j-spring-boot-starter/artifactId version3.0.3/version /dependency然后在Controller上加Swagger注解就可以通过http://localhost:8080/doc.html查看接口文档还带调试功能比Postman还方便。这里要特别强调一下接口文档的意义不只是给老师看的更是给你自己看的。前后端联调时前端同学或你自己写的Vue代码要对接接口没有文档就得回头看代码效率极其低下。有了Swagger之后请求参数、返回结构一目了然开发效率直接翻倍。4. 前端Vue实现从登录页到游戏管理后台前端部分的工作量其实不比后端少但很多人低估了它的难度。我见过太多人把Vue代码写成HTMLJS缝合怪——没有组件化、没有路由管理、没有状态管理代码堆在一起能运行但一团糟。这种代码拿来毕设答辩时老师一眼就能看出技术含量不高。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.jsimport 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 classgame-manage el-card div classsearch-bar el-input v-modelqueryParams.name placeholder游戏名称 stylewidth: 200px / el-select v-modelqueryParams.status placeholder状态 el-option label全部 value / el-option label已上架 value1 / el-option label已下架 value0 / /el-select el-button typeprimary clickloadList查询/el-button el-button typesuccess clickopenDialog()新增游戏/el-button /div el-table :datatableData border stripe el-table-column propname label游戏名 / el-table-column propcategoryName label分类 / el-table-column propprice label价格 / el-table-column propstatus label状态 template #default{ row } el-tag :typerow.status 1 ? success : info {{ row.status 1 ? 已上架 : 已下架 }} /el-tag /template /el-table-column el-table-column label操作 template #default{ row } el-button sizesmall clickopenDialog(row)编辑/el-button el-button sizesmall typewarning clicktoggleStatus(row) {{ row.status 1 ? 下架 : 上架 }} /el-button el-button sizesmall typedanger clickdeleteGame(row)删除/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequeryParams.pageNum :page-sizequeryParams.pageSize :totaltotal layouttotal, prev, pager, next current-changeloadList / /el-card !-- 新增/编辑对话框 -- el-dialog v-modeldialogVisible :titleform.id ? 编辑游戏 : 新增游戏 width500px el-form :modelform label-width80px el-form-item label游戏名称 el-input v-modelform.name / /el-form-item el-form-item label分类 el-select v-modelform.categoryId el-option v-foritem in categoryList :keyitem.id :labelitem.name :valueitem.id / /el-select /el-form-item el-form-item label价格 el-input-number v-modelform.price :min0 :precision2 / /el-form-item el-form-item label简介 el-input v-modelform.description typetextarea / /el-form-item el-form-item label封面图 el-upload :actionuploadUrl :headersuploadHeaders :on-successhandleUploadSuccess el-button上传图片/el-button /el-upload /el-form-item /el-form template #footer el-button clickdialogVisible false取消/el-button el-button typeprimary clicksubmitForm保存/el-button /template /el-dialog /div /template这是典型的管理后台页面所有模块分类管理、订单管理、用户管理都可以复刻这套模式。需要注意的是分页参数的传递——pageNum、pageSize要与后端接口的PageT分页对象对接好。4.4 前端状态管理与用户信息持久化游戏管理平台的前端状态管理我用的是PiniaVue3或VuexVue2主要存三类信息用户信息userInfo包括昵称、头像、角色登录状态isLoggedIn页面刷新后从localStorage恢复购物车数量cartCount用于首页导航栏红点显示要注意的是页面刷新后Vuex/Pinia中的数据会丢失所以要在store的初始化逻辑里从localStorage读取已保存的状态。这个细节处理不好就会出现刷新后导航栏上的用户名没了的尴尬问题。5. 前后端联调与部署最容易翻车的环节功能代码都写完了接下来就是联调和部署。这个环节踩坑概率极高而且基本都是集成类问题。不是单个模块不工作而是模块之间接不上。这里把我踩过的坑都列出来。5.1 跨域问题前后端分离的经典拦路虎本地联调时前端跑在http://localhost:5173Vite默认端口后端跑在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?useUnicodetruecharacterEncodingutf-8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver几个值得注意的细节serverTimezoneAsia/Shanghai必须加否则MySQL 8.x时差问题会让你所有时间字段都不对useSSLfalse是避免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配置是否生效前端代理路径是否匹配接口返回404Controller的RequestMapping路径是否与前端请求一致数据库中文乱码数据库连接URL中characterEncodingutf-8是否配置数据库本身的字符集是否是utf8mb4上传图片预览不了文件上传路径是否可写静态资源映射是否配置刷新页面404Vue路由history模式SprintBoot兜底转发是否配置6. 复盘与答辩准备一个能拿优秀的毕设项目应该有什么项目做完了代码能跑、功能齐全这只是底线。想拿高分甚至优秀还需要在细节上多下功夫。这节说说我在答辩和复盘时的经验和教训。6.1 代码脏乱差的常见扣分点答辩时老师看代码比你想象中仔细但也不是逐行阅读他们主要关注几个地方包结构是否清晰杂乱无章的包名和类是第一印象非常影响评分是否有重复代码比如多个Controller里重复写分页逻辑这是明显的代码质量问题密码是否明文存库密码用MD5或BCrypt加密是最基本的底线SQL注入风险用了MyBatis的${}拼接字符串一查一个准必须用#{}异常处理是否得当Controller里大段大段的try-catch吃掉异常还打印e.printStackTrace()观感极差6.2 答辩时必被问到的几个技术问题作为项目作者你要能回答为什么的问题。我整理了一些高频问题供参考为什么选MyBatis-Plus而不直接写SQLMyBatis-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系统的能力。对于准备答辩的人来说提前把每个模块的为什么想清楚比你把代码背下来更管用。