Spring Boot + Vue游戏售卖商城系统开发：从选题设计到答辩全流程解析

又是一年毕设季后台咨询里“Java毕设做什么”永远是最多的一个问题。如果你正在纠结选题又希望项目既有完整业务闭环、技术栈主流还能顺利通过答辩那基于 Spring Boot 的游戏售卖商城系统是一个很稳的选择。这个项目表面看起来是一个电商系统但实际覆盖了用户管理、商品展示、购物车、订单流转、库存扣减、支付对接等一系列完整业务模块。它不像仿抖音、仿B站那样重前端交互也不像纯管理系统那样功能单薄属于“前后端都有、业务链条完整、技术点足够答辩”的均衡型选题。这篇文章我会从选题逻辑、技术选型、数据库设计、核心功能实现到调试答辩把整条链路里你真正会遇到的细节和坑全部过一遍。1. 项目定位为什么“游戏商城”是合适的毕设选题1.1 选题不必“高精尖”但必须形成业务闭环很多同学有个误区觉得毕设题目越前沿越好微服务、分布式、高并发这些词全堆上去结果自己连项目都跑不起来。毕设答辩老师的核心关注点其实是三件事项目完整性、工作量、你对代码的熟悉程度。所谓完整性指的是从用户登录到商品浏览、下单、支付、订单查询一条龙走完数据有流转、状态有变化、表与表之间有关系。游戏售卖商城恰好满足这个闭环。对比同类选题图书管理系统功能太浅库存管理复杂度低答辩时不好展开仿一个短视频平台需要处理视频上传、流媒体转码工作量又失控。游戏商城属于典型的中等复杂度电商系统既有商品搜索和分类筛选这种查询逻辑又有购物车合并、订单状态切换这种状态逻辑还有库存扣减这种并发敏感点。难度刚刚好。1.2 这个项目真正要解决的三类核心问题从业务层面拆解游戏售卖商城要解决三件事。第一是商品信息的高效展示与检索。游戏商品不同于普通衣服鞋子它有平台分类PC端游、手游、主机游戏、有价格区间、有折扣属性、有库存状态。用户在首页怎么看到商品列表关键词搜不到时怎么处理分类筛选和排序如何组合这些都是可以写进论文、拿到答辩现场讲的实际问题。第二是交易链路的状态管理。用户把商品加入购物车、提交订单、支付、管理员发货、确认收货每一步订单状态都要准确切换。这里最怕的就是状态散落在代码各个地方改一处漏三处。项目里必须有一张订单表加上明确的状态枚举才能把链路讲清楚。第三是用户与后台的权限边界。普通用户能看商品、能下单、能查自己的订单管理员能上下架商品、修改库存、处理订单发货。两个角色不能串权限这涉及登录态和角色校验也是答辩时老师一定会追问的点。2. 技术选型的底层逻辑与项目结构规划2.1 Spring Boot MyBatis Plus 的组合为什么稳技术栈选择上Spring Boot 是当前 Java 领域绝对的主流框架只要简历里写 Java 后端Spring Boot 几乎是标配。它解决了传统 SSM 项目里大量 XML 配置的问题内嵌 Tomcat、自动装配、起步依赖这些特性让新手也能很快跑起来。持久层我建议用 MyBatis Plus 而不是纯 MyBatis。原因很简单单表 CRUD 不需要手写 SQL 了BaseMapper 里已经封装好 insert、update、selectById 这些通用方法分页插件直接用分页拦截器写一个 Page 参数传进去就能返回分页结果条件构造器 QueryWrapper 应对动态查询比如价格区间、分类筛选非常顺手。这些功能对开发效率的提升是肉眼可见的。有同学担心用了 MyBatis Plus 显得没技术含量答辩时老师问 MyBatis 怎么办这个担心其实多余。你可以在简历和论文里写“基于 MyBatis Plus 提升单表开发效率复杂多表关联仍使用自定义 SQL 实现”这句话本身就体现了你的技术判断。数据库方面用 MySQL 8.0关系型数据库在交易系统里依然是绝对主流。缓存要不要加 Redis我的建议是如果你的项目时间充裕可以把 Redis 用在验证码存储和首页热门商品缓存上属于锦上添花如果时间紧张不加也完全不影响项目完整性。先把核心链路做通再谈性能优化。2.2 前端方案服务端渲染还是前后端分离游戏售卖商城的页面展示要求比管理系统高但又不如专业的电商平台那么复杂。前端方案有两条路第一条路是 Thymeleaf 服务端渲染。模板引擎直接写在 Spring Boot 项目里数据由 Controller 塞进 Model页面在服务端渲染完成后返还给浏览器。优点是项目结构简单、部署方便、不需要考虑跨域问题适合一个人完成的毕设项目。缺点是页面交互弱点击加入购物车需要整页刷新或者靠少量 JS 处理。第二条路是前后端分离后端提供 JSON 接口前端用 Vue 独立开发。你的项目如果定位于“展示能力”或者你的简历需要体现前端技能选这条路更有说服力。代价是项目规模翻倍前端工程要单独写、跨域要处理、联调要多花时间。我个人更推荐你现在这个标题描述的场景选择 Vue 前后端分离方案。因为游戏商城天然需要更好的视觉体验而 Thymeleaf 写出来的页面在答辩时确实撑不住场子。后端保持 Spring Boot 端口 8080前端 Vue 开发时用 8081通过代理转发接口同时解决跨域问题。部署时前端打成静态资源放进后端项目的 static 目录下或者直接用 Nginx 托管前端。2.3 项目目录结构与分包策略分包方式直接体现代码组织能力。实际开发中我建议这样的后端结构src/main/java/com/example/gameshop ├── common # 公共类统一返回体、异常处理、工具类 ├── config # 配置类拦截器配置、跨域配置、MP分页插件 ├── controller # 接口层 ├── service # 业务层接口 实现类 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto # 前端传参对象 ├── vo # 返回前端的数据对象 └── GameshopApplication.java你注意看我把 entity 和 vo 分开是有讲究的。很多新手直接把数据库实体返回给前端结果密码字段、逻辑删除字段全暴露了。正确的做法是 Controller 永远不直接返回 entity而是转成 VOView Object返回。这个细节在答辩时讲出来老师会觉得你有真实项目经验。service 层为什么要写接口再写实现类这是以前 SSM 时代留下的规范Spring Boot 项目其实可以不这么做。但考虑到毕设论文里类图好画、老师习惯性要看到 Service ServiceImpl 的结构建议保留这个习惯。前端如果是 Vue 项目目录按 views页面、components组件、router路由、store状态管理可选、api接口封装来组织。api 目录里按模块拆文件比如 User.js、Order.js每个文件里封装 axios 请求避免组件里到处散落请求代码。3. 数据库设计反推表结构先把关系理清3.1 从业务关系回归数据模型数据库设计是毕设答辩里提问最密集的部分。我习惯先梳理清楚实体关系再落到建表语句上。游戏商城项目里核心实体关系是这样的用户和订单是一对多一个用户能下多个订单订单和订单项是一对多一个订单包含多个游戏商品虽然实际买游戏一般是一单一款但设计上要保留数量字段做通用性商品和分类是多对一一个分类下有多个游戏用户和购物车大概是一对一关系购物车项与商品是一对多。搞清楚关系后表结构其实就清楚了。这里有个特别容易被忽视的点要不要建购物车表如果用户每次加购只是弹个提示、前端 localStorage 存一下那后端就没有购物车模块工作量大打折扣。我的建议是后端保留购物车表哪怕前端做得简单一点数据库层的完整性对答辩帮助很大。3.2 核心表的字段设计与类型选择用户表 users我建议字段这样设计id、username用户名唯一、password密码BCrypt 加密存储、nickname、avatar、phone、email、role0 普通用户 / 1 管理员、status是否禁用、create_time、update_time。密码只能存加密后的字符串这个没得商量。游戏商品表 game字段有id、game_name、category_id关联分类表、cover封面图 URL、price原价、discount_price折扣价、description游戏简介、platform平台如 PC、PlayStation、Switch、stock库存、sales_count销量、status0 下架 / 1 上架、create_time。价格字段用 decimal(10,2) 而不是 double因为浮点数计算会丢失精度这个知识点在答辩时经常被问到。分类表 category 很简单id、category_name、sort_order。字段少不代表不重要首页的分类导航和侧边栏筛选都靠它。订单表 orders 是整个系统状态最复杂的表。字段至少要有id、order_no订单编号建议时间戳 随机数生成、user_id、total_amount、status0 待支付 / 1 待发货 / 2 已发货 / 3 已完成 / 4 已取消、address、receiver_name、receiver_phone、pay_time、deliver_time、finish_time、create_time。订单状态字段在 Java 里用枚举常量限定取值防止散落的魔法值。订单项表 order_itemid、order_id、game_id、game_name、game_cover、price下单时刻单价、quantity、subtotal。为什么订单项里要冗余 game_name 和 cover因为商品信息可能被修改或者下架但历史订单里的快照不能变。这个设计叫“数据快照”面试和答辩都是加分点。购物车表 cartid、user_id、game_id、quantity、checked是否选中如果做结算功能会用到、create_time。加一个联合唯一索引user_id, game_id防止同一用户重复添加同一商品。3.3 库存扣减与订单状态关联的坑库存字段虽然只有一个 stock但它牵动的逻辑不少。当用户提交订单时系统要扣减库存如果用户取消订单要回补库存支付超时未付款订单自动取消后同样要回补库存。这三个动作每个都要在事务里完成并且要同时修改 order 状态字段和 game 表的 stock 字段。实际开发里最简单的做法是在提交订单的方法上加 Transactional 注解先判断 stock 是否大于等于购买数量再 update 库存最后插入订单数据。千万别把判断库存和扣减库存拆成两次独立操作中间一旦有其他请求插进来就会超卖。刚上手做项目的时候最容易在这个位置出并发问题答辩老师也很喜欢从这个角度发问。4. 核心功能实现与代码逃坑指南4.1 登录鉴权从 Session 到 JWT 的取舍登录模块是每个系统都有的功能但实现方式直接影响后续开发。毕设项目里两种主流方案Session 方案简单直接。Spring Boot 自带 HttpSession用户登录成功后把用户对象存进 session后续请求通过拦截器判断 session 里有没有用户。优点是代码量小、不需要额外依赖缺点是前后端分离场景下要处理 Cookie 跨域携带问题体验一般。JWTJSON Web Token方案更现代化。用户登录成功后后端生成一个带有用户 id 和角色信息的 token 字符串返回给前端前端每次请求在请求头里带 Authorization 字段后端通过拦截器每次解析 token识别当前用户身份。缺点是 token 失效管理麻烦但在前后端分离项目里这是主流做法。我建议这个游戏商城项目用 JWT。理由之一是可以直接在答辩时讲“无状态认证”体现你对现代 Web 开发的理解。具体实现是引入 jjwt 依赖写一个 JwtUtil 工具类负责生成和解析 token再写一个拦截器实现 HandlerInterceptor 接口在 preHandle 方法里解析请求头中的 token然后把用户信息放入 ThreadLocal后面业务代码随时能从 ThreadLocal 取当前登录用户。拦截器注册需要注意要排除登录接口、注册接口、首页商品列表和详情接口因为这些是未登录也能访问的。别把静态资源路径也拦截了否则前端页面全白屏。我自己初做这个项目时就被静态资源 401 卡了半下午。4.2 商品检索与分页最容易暴露代码水平的地方商品列表页一般有三个维度的检索条件关键词搜游戏名、分类 id、价格区间或排序价格从低到高、销量优先、最新上架。MyBatis Plus 的 QueryWrapper 在这里非常好用。QueryWrapperGame wrapper new QueryWrapper(); if (StringUtils.hasText(keyword)) { wrapper.like(game_name, keyword); } if (categoryId ! null) { wrapper.eq(category_id, categoryId); } wrapper.eq(status, 1); wrapper.orderByDesc(sales_count); PageGame page new Page(current, size); gameMapper.selectPage(page, wrapper);这段代码里要注意三个点like 查询对 keyword 做了空值判断防止拼出WHERE game_name LIKE %%这种全量查询eq 条件只有分类不为空才拼接最后加了一个排序规则。实际项目还可以加一个 sortType 参数从前端传入然后动态设置不同的排序字段。分页信息总记录数、总页数、当前页、每页大小统一封装在返回的 vo 对象里前端只需要展示数据。这里有个数据库层面的小知识商品表数据量大了之后orderByDesc(sales_count)这类排序需要建索引否则查询慢。毕设项目数据量小感觉不到但如果你在论文里写了“对销量字段建立索引以优化排序查询”这是很扎实的一句话。4.3 订单流程核心链路的时序控制订单模块是整个系统的核心我建议实现顺序是创建订单 → 支付回调 → 发货 → 确认收货 → 取消订单。创建订单时要注意几个动作必须在一个事务里校验游戏是否上架、校验库存、扣减库存、计算金额、生成订单号、插入订单主表、插入订单项表、清空对应购物车项。业务方法上标注Transactional(rollbackFor Exception.class)保证任何一步异常都会整体回滚不会出现库存扣了但订单没生成的脏数据。订单号生成有一个常见误区直接用系统当前时间new Date().getTime()拼接随机数。高并发下重复概率很高。更稳妥的方式是使用时间戳加随机字符串的组合或者引入雪花算法。毕设项目里用GD yyyyMMddHHmmss 4位随机数作为订单号就足够了。支付模块是这个项目最微妙的部分。真正对接微信支付或者支付宝需要商户号、证书、回调地址而且回调需要公网 IP 才能被支付平台访问非常麻烦。毕设项目最合理的做法是模拟支付流程订单创建成功后前端弹出支付确认框用户点击去支付后端直接把订单状态从待支付改成已支付同时记录支付时间。你可以在论文里写“支付模块采用模拟支付方式核心逻辑为订单状态流转控制真实支付接入预留接口扩展”这个说法是诚实且合理的。4.4 后台管理功能与文件上传问题商城必然有一个后台管理模块。管理员登录后台后能看到商品管理新增、编辑、上下架、订单管理查看订单列表、发货、用户管理查看用户列表、禁用账号以及数据统计今日订单数、销售额、热门商品Top10。这个模块的代码量不小但大多是简单的 CRUD。商品新增时涉及图片上传本地开发可以直接保存到服务器磁盘目录然后把相对路径存数据库前端用img标签加载。生产环境如果做不了对象存储比如 OSS把图片放在后端 static 资源目录也是一种过渡方案但没有专业属性。为了稳妥建议写一个文件上传接口控制文件大小在 5MB 以内后缀名做白名单校验jpg、png、webp这是我在实际项目里吃过亏才知道要加的。后台数据统计要写几条聚合 SQL。比如统计今日销售额SELECT COALESCE(SUM(total_amount), 0) FROM orders WHERE status IN (1, 2, 3) AND DATE(pay_time) CURRENT_DATE再用GROUP BY game_id结合ORDER BY sales_count DESC LIMIT 10做热门游戏排行。这些语句复杂度适中写在论文的数据分析相关章节里非常合适。5. 调试运行与毕设答辩全流程避坑指南5.1 本地启动项目的完整步骤项目拿到手或自己重写代码第一次运行的顺序极其关键。先启动 MySQL选择 3306 默认端口然后创建数据库game_shop数据库字符集我建议用utf8mb4如果游戏介绍里包含特殊符号utf8 会有兼容问题导入项目附带的 SQL 脚本。接着修改后端application.yml里的数据库账号密码。启动后端之前先确认端口 8080 没有被占用。然后在浏览器访问http://localhost:8080/api/game/list之类的接口看能否正常返回 JSON。再启动前端如果用了 Vue先npm install再npm run serve访问 8081 端口。前后端联调时配置 Vue 的 proxy 代理转发/api到 8080。这套流程顺手之后五到十分钟就能把环境跑起来。项目跑不起来的时候先看日志这是最重要的习惯。尤其注意 Spring Boot 启动时有没有报“数据库连接失败”“端口被占用”“找不到主类”这几种经典错误。很多时候问题不是代码本身而是环境变量或者依赖没有装好。5.2 运行阶段最容易踩的五个坑第一个坑是数据库连接串写错。jdbc:mysql://localhost:3306/game_shop?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8一个参数都不能少特别是 serverTimezone不设置会报时区异常。第二个坑是 Lombok 没装插件。代码里用了Data注解但 IDE 里没安装 Lombok 插件就会疯狂报找不到 getter/setter。如果你用 IDEA在插件市场搜索 Lombok 安装并重启Eclipse 用户还需要额外运行一下 apt 的配置。第三个坑是 Maven 依赖下载缓慢或失败。建议在settings.xml里配置国内镜像源比如阿里云的仓库镜像。毕设项目用到的依赖数量不少这个配置能帮你省下大量等待时间。第四个坑是前端跨域报错浏览器 console 里出现CORS字样。解决方式是在 Spring Boot 里写一个跨域配置类实现 WebMvcConfigurer重写 addCorsMappings 放行前端地址。如果前后端联调用的是代理后端不一定需要开放跨域但为了稳妥建议两层都配置好。第五个坑是静态资源 404。把前端打好的 dist 目录放进src/main/resources/static之后记得先 clean 再重新编译否则旧的静态资源还在 target 目录里刷新也没用。5.3 答辩演示时的加分操作答辩演示是有策略的别从头到尾安静地点按钮。演示前把项目先跑起来数据库导入好测试数据最好准备一个管理员账号和一个普通用户账号同时打开两个浏览器窗口一个正常模式、一个无痕模式。演示时先以普通用户身份走一遍完整流程登录 → 首页浏览商品 → 搜索 → 筛选 → 加购 → 结算 → 模拟支付 → 在我的订单里看到待发货订单。然后切换管理员窗口登录管理后台 → 看到刚才那个订单 → 发货 → 再到用户窗口刷新发现订单状态变成已发货。这样一个闭环演示下来系统功能基本全部覆盖。重点讲一下你在技术上有思考的地方比如库存扣减为什么用事务、JWT 拦截器做了什么、订单状态为什么用枚举管理、订单项为什么冗余商品信息快照。这些点比“我用了 Spring Boot”值钱得多。演示时还要注意别把敏感接口暴露出来。查看商品详情时如果看到商品表的主键 id 是 1、2、3 这种自增接口又允许直接访问很可能会被老师说“存在越权访问风险”。如果提前做了登录拦截和角色校验你在演示时主动提一句“后台接口做了角色权限校验非管理员无法访问”这就是加分项。6. 二次开发与实际部署场景的延展思路6.1 项目后续可以扩展的方向如果你在完成基础版本之后还有精力这里提供几个成本低、亮点足的扩展方向引入 Spring Cache 做首页热门商品的缓存热点数据先在缓存里查查不到再回源数据库。这个思路实现起来不复杂在答辩里可以说是性能优化的细节体现。引入消息队列做订单超时未支付自动取消。模拟支付场景下核心逻辑是订单创建后放进延迟队列超过规定时间仍未支付就自动置为已取消。这个需求可以直接用 RocketMQ 的延迟消息实现当然你可以先用定时任务轮询订单表代替效果一样好讲。引入 RBAC 权限模型。当前系统只有用户和管理员两种角色后续可以扩展为超级管理员、运营、普通用户等多角色细粒度到按钮权限。这在权限设计层面是一个很大的加分项。6.2 部署上线时如何选择服务器如果导师要求项目必须能通过公网访问部署到云服务器是最现实的方案。这里强调一下需要注意的节点是购买轻量应用服务器时选择预装 Ubuntu 或 CentOS 的镜像然后自己装 JDK、MySQL、Nginx。部署流程三步走后端打成 jar 包java -jar启动前端执行npm run build产出 distNginx 把 80 端口指向 dist 目录同时把/api的请求反向代理到 8080 端口。服务器配置不必高2核4G内存足够跑这个项目选最低档的轻量应用服务器对毕设来说绰绰有余。部署过程中最容易出问题的是用 root 直接跑 jar学一下用nohup让进程在后台运行再配合重定向日志文件的方式nohup java -jar game-shop-backend.jar app.log 21 第一次部署踩坑最多的其实是 MySQL 的远程连接权限问题。云服务上拿到新数据库默认只能本机访问想让后端连上得创建一个允许远程访问的账号同时要在防火墙的安全组放行 3306 端口。这两步没做对后端永远报数据库连接失败。如果前端也部署在同一台机器Nginx 静态目录下的文件权限不要设成 777用默认的权限即可。为的是避免被扫描攻击。在实际做这个项目的过程中我最大的体会是毕设不是越复杂越好而是越完整越好。游戏商城这种题目麻雀虽小五脏俱全它逼着你去处理真实业务里的状态流转、数据一致性、角色权限这些问题而这些恰恰是你在面试时最容易被问到的内容。把这个项目每一个模块的逻辑吃透你收获的远不止一个学分。最后再分享一个小技巧建议你从一开始就用 Git 管理代码每次完成一个功能就提交一次commit message 写清楚。这不光是为了防止电脑崩溃丢代码更重要的是一份清晰的开发历史就是你项目工作量最直接的证明。很多同学到答辩前一周才开始写论文对着空空如也的代码仓库编功能描述那个痛苦我见过太多了。从第一天养成好习惯后面会顺很多。