每年到这个时间就有不少同学开始对着毕业设计选题发愁。去年我也被一个“游戏周边商城”折腾了两个多月最后用SpringBoot把整套系统完整跑通了从数据库设计到前端页面、从购物车到模拟支付前后端一条链路全走了一遍。今天我就把这个项目的思路、表结构、核心模块、部署方式、踩过的坑全部复盘出来。这套方案尤其适合计算机毕业设计、课程设计或者想拿SpringBoot练手电商系统的同学做完之后你对SpringBoot的掌握程度会比只看教程扎实很多。先说清楚这个项目到底是干什么的。游戏周边商城本质上就是一个聚焦游戏装备、手办、键鼠、耳机、定制外设等商品的交易管理系统包含前台用户浏览购物和后台管理员运维两个核心端。前端要支持注册登录、商品分类展示、关键词搜索、购物车、下订单、模拟支付、订单管理后台要支持商品上架下架、库存管理、订单发货、用户管理、基础数据统计。整条链路不算复杂但“用户-商品-购物车-订单-支付-发货”这个交易闭环非常完整恰好是毕业答辩时最能讲清楚业务逻辑的范围不至于太简单被质疑工作量也不会复杂到做不完。1. 项目定位与技术选型为什么这套系统是毕设的稳妥之选1.1 这个系统到底要解决什么问题游戏周边商品交易管理系统听起来有点正式实际拆开就是一条电商业务线。游戏爱好者进到商城看到的是一排排分类好的周边商品点击某个商品能看到详情、价格、库存加进购物车后统一结算结算时选择收货地址提交订单后模拟支付支付完后台管理员能看到订单并安排发货用户收到货后可以评价和确认收货。这里面的核心不只是“能增删改查”而是要把交易状态、库存变化、订单金额、用户数据这些关联起来。比如用户下单购买一个限量手办库存扣了但订单没生成或者订单生成了但库存没扣这都属于业务逻辑错误也是答辩时老师最喜欢追问的点。所以做这个项目时我一开始就不是按照普通的CRUD来写而是按“电商交易系统”的真正业务规则来设计只不过技术实现上控制在本科毕设能完成的范围内。1.2 技术栈取舍能做完比花哨更重要技术选型我建议不要追求最新最炫要选你最有把握、文档最多、遇到问题最容易搜索到答案的组合。我最终用的是以下这套技术组件选择方案选型理由后端框架SpringBoot 2.7.x稳定、生态成熟、内置Tomcat毕业设计最常用JDK版本JDK 8 或 11避免SpringBoot 3强制JDK17带来的环境折腾持久层MyBatis-Plus单表CRUD快到离谱分页插件好用论文里也好解释数据库MySQL 5.7 / 8.0关系型数据库电商业务最合适模板方案Thymeleaf Bootstrap服务端渲染为主页面代码少答辩演示可靠前端交互jQuery Ajax局部刷新购物车、提交订单够用且简单认证方式Session 拦截器比JWT更适合服务端渲染断点调试容易密码加密BCrypt直接引入靠谱加密工具绝不明文存密码构建工具Maven标准配置打包部署一条命令文件上传本地磁盘存储服务器上传目录加虚拟路径映射避免搞对象存储这里重点说下为什么我建议用Thymeleaf而不是前后端完全分离。很多同学一上来就想搞Vue SpringBoot做成前后端分离项目看着高级实际给自己挖坑。毕设场景下服务端渲染天然方便处理登录状态、权限拦截和数据回显后端返回页面直接刷新逻辑都在Service层里代码量小调试简单。前后端分离意味着要同时维护两套工程、处理跨域、处理Token、联调时间完全不够用。如果你想在项目中体现前后端交互能力只需要在购物车、结算页、后台发货这些地方用Ajax请求局部刷新已经足够体现你的开发能力了。2. 数据库设计商城项目的命脉2.1 九张核心表怎么划分做电商系统数据库设计做不好后面写代码会越写越痛苦。我按照业务边界拆成了九张核心表分别是用户表、管理员表、商品分类表、商品表、购物车表、收货地址表、订单表、订单明细表、评价表。用户表和商品表不用多说单表存基础信息就好。商品分类表和商品表是典型的父子关系一个分类下挂多个商品商品表里存category_id作为逻辑外键。购物车表不能直接做成Redis里的临时数据虽然Redis放购物车性能好但对毕设来说持久化到MySQL反而更容易理解也方便演示购物车历史数据。地址表单独拆出来是因为一个用户可能有多个收货地址下单时不能再要求用户重新输入地址必须从地址表里去选。这里我想单独强调一下用户和管理员为什么要分开两张表。部分同学习惯在user表里加一个role字段来区分用户和会员这种做法虽然也能实现权限控制但后台管理员的字段和前端用户差异很大管理员有权限级别、最近登录时间用户有头像、昵称、手机号。拆成两张表后两个登录入口的校验逻辑完全隔离后台管理模块不需要每次判断当前用户身份代码写起来干净很多。2.2 订单表与订单明细表为什么要拆两张表订单表存一次结算产生的汇总信息订单明细表存这条订单里每一个商品的信息。拆开的好处有三个。第一一次买五个商品订单表只存一条记录明细表存五条符合电商“一单多品”的真实结构。第二商品的价格、名称、图片都有可能变化而订单一旦生成就不能跟着变所以明细表里要冗余商品名称、商品图片、购买时的单价这就是常说的“订单快照”。第三后续如果要扩展售后、部分退款功能把订单和明细拆开才做得动不拆的话一个退货需求就能把结构改崩溃。订单表里我特别设计了address_snapshot字段把收货人、电话、省市区、详细地址拼成一个JSON字符串存进去。这个做法可能有人觉得不规范但它体现的是真实业务里的快照思想——用户下单之后如果修改了默认地址订单历史里收货地址不应该跟着变。把地址详情冗余进订单表查询订单时直接取快照不用再关联地址表逻辑也简单很多。订单状态字段我只用了int类型0代表待支付1代表已支付待发货2代表已发货3代表已完成4代表已取消。用状态数字而不是字符串一方面节省空间另一方面状态流转写代码判断时更清晰。状态机线上流转为0到1到2到30状态下用户可以取消变成4待支付状态下超过30分钟也可以自动关闭这些规则不用过度设计但必须提前定义好否则写业务逻辑时会不知道从哪里判断。金额字段一定要用decimal(10,2)千万别用float或double这是所有做电商的同学最容易踩的坑。浮点型在计算机里是近似存储算钱的时候会多出0.0000001这种莫名其妙的小数虽然一次就差一点点但订单总额、销量统计一放大会非常难看。decimal(10,2)能够精确表示到分完全满足商城金额需求。2.3 索引、冗余字段与防超卖设计数据库层面还有一个容易被忽略的点索引。毕设数据量虽然不大但答辩老师一定会问“你的数据库有没有优化”。我在这几个位置加了索引订单表的user_id和status联合索引因为后台列表经常按用户查订单订单明细表的order_id索引因为要根据订单查明细商品表的category_id和is_on_sale索引因为前台列表页频繁按分类和上架状态筛选用户名和商品名称字段有余力也可以加普通索引优化like搜索。商品表还设计了两个非常重要的字段stock和sales。库存字段不只是显示给用户看更是防超卖的关键。销售数字则用于“销量排序”和商品详情页的“已售XX件”这个字段每次下单成功后同步累加不需要实时去订单明细表里count省一次大查询。这种冗余字段的设计论文里讲起来就是“以空间换时间的优化手段”属于答辩加分项。3. 后端核心链路实现从登录到下单全流程3.1 登录认证与拦截器登录这块我用Session配合拦截器实现。用户登录成功后把用户对象放进Session前端登录状态用Thymeleaf从Session取值判断是否显示“登录”还是“用户名/退出”。后台管理员走同一个套路只是换成admin的Session标识。真正麻烦的是拦截器配置。我建议把“需要登录”的路径和“不需要登录”的路径分开梳理。比如首页、商品列表、商品详情可以匿名访问但购物车、结算页、个人订单必须登录。静态资源比如CSS、JS、图片必须放行否则页面样式会整个崩掉。拦截实验里最容易遇到的坑是Ajax请求被拦截后跳转登录页。浏览器发送Ajax时如果后端返回一个302重定向前端拿到的其实是登录页的HTML然后你的前端代码会在控制台报出各种奇怪的解析错误。解决思路很简单在拦截器里判断请求头有没有X-Requested-WithXMLHttpRequest如果有就返回JSON提示未登录前端收到后自己跳转登录页。密码存储必须用加密算法。我直接用了加密工具生成BCrypt密文数据库里存的是密文而不是明文登录时把用户输入的密码用校验函数比对。为什么强烈不推荐自己写MD5加盐因为MD5速度快容易被暴力破解BCrypt每次算出结果都不一样自带随机盐暴力破解成本高得多。其实毕设阶段只需要记住结论凡涉及密码不进明文加密算法选成熟库里的现成工具不要自己造轮子。3.2 商品搜索、分类与分页商品列表页是前台访问频率最高的页面核心功能就是三个分类筛选、关键词搜索、分页排序。分类筛选很简单按category_id查询即可。关键词搜索用name字段的模糊查询这里要强调绝对不能自己拼接SQL字符串而是用MyBatis-Plus的QueryWrapper来做like条件参数化查询天然防SQL注入。答辩时老师问“你怎么防SQL注入”你就说所有条件都走预编译的QueryWrapper不接受任何用户的原生SQL片段这个回答非常干净。分页我用的是分页插件引入后只需要在配置类中注册一个分页拦截器然后在Service里构造Page对象给它传当前页码和每页条数插件会自动生成limit语句。排序方面常见的是按销量、价格、上架时间三种排序方式。排序字段建议在前端传一个固定的sort参数后端用switch映射成固定的排序列名而不是直接把前端传的字符串拼进order by否则容易被拼入异常内容。3.3 购物车与库存扣减购物车表相对简单每条记录对应“某个用户的某个商品的某件数量”。加购接口要注意一个重复加购的问题同一商品已经加过购物车再次点击加购时应该数量1而不是新增一条记录否则购物车列表会出现两行相同商品。实现时先按user_id和product_id查一次存在就更新数量不存在就插入。库存扣减是整个商城系统里最容易出大问题的地方需要用事务保证多表操作的原子性。下单时的正确流程是先校验商品是否存在、是否上架、库存是否充足然后扣减库存随后生成订单和订单明细。这几个步骤必须全部放在同一个事务方法里任何一个环节抛异常整个操作回滚不能让“库存扣了但订单没生成”这种脏数据出现。扣减库存的SQL写法也有讲究直接先查库存再在Java代码里减一个数再update在并发场景下会出现超卖。更稳妥的写法是一条update语句一次性完成“扣减并校验”比如商品库存从当前值减1同时要求原库存大于等于购买数量受影响行数为0说明库存不足。这段逻辑是毕设里少有的能体现“并发安全”意识的点一定要在论文或答辩中讲出来。3.4 订单创建与模拟支付订单创建方法接收一个用户ID、收货地址ID、购物车里的商品列表返回值是创建好的订单编号。订单号不能随便用自增ID因为对外暴露容易暴露业务量而且主键ID和订单编号混用会乱。我封装了生成规则当前时间精确到毫秒、拼接四到六位随机数、再拼接用户ID的后几位。格式类似2025120715302212345678唯一性和可读性都兼顾。这里还有一个重要的设计思想就是“下单时再查一遍商品价格”。购物车里虽然已经展示了价格但用户在购物车页面停留了十分钟商品价格可能已经被管理员调整过。所以创建订单时不能直接用购物车里的价格而要从数据库重新读取商品最新价格用最新价格去计算订单金额并写入订单明细。这个细节体现了电商系统对金钱交易的严谨态度平时自己练习没感觉但是老师问“你如何保证价格准确”这就是标准答案。支付模块在毕设里只能做模拟。真实接入支付渠道需要企业资质、商户号、证书个人开发者基本没戏也不需要真接通。我的做法是提交订单后跳到支付确认页页面上展示订单号、应付金额和一个“模拟支付成功”按钮点击后调用后端支付接口校验订单状态确实为待支付然后更新状态为已支付再记录支付时间。同时还可以写一个简单的“取消订单”接口在待支付状态下允许用户取消并恢复库存。超时未支付处理也是答辩老师喜欢问的点。我采用的方案是支付接口里判断订单创建时间是否超过30分钟如果超时就拒绝支付并提示订单已过期。这属于“懒处理”方案不需要定时任务轮询数据库代码量小逻辑清晰。如果你有余力可以再写一个定时任务每天扫描超时订单并批量关闭但要注意关单时也涉及库存恢复和事务缺一不可。4. 前端页面与前后端对接细节4.1 页面方案模板渲染为主Ajax为辅前端如果完全靠手写原生HTML加CSS工作量会高到怀疑人生所以我选择了Thymeleaf加Bootstrap的组合。页面布局采用非常经典的上中下结构顶部是导航栏包含Logo、搜索框、分类入口、购物车和登录用户信息中间是内容区域根据路由渲染商品列表、详情、购物车、结算页等底部是版权和友情链接。模板渲染的优势在于像商品列表这种页面后端返回一个Model并填充商品集合Thymeleaf在HTML里用th:each循环渲染即可。不需要额外发起Ajax拿数据不需要处理JSON解析直接刷新页面就出来结果。这种写法的体验很像传统的Java Web开发对基础薄弱的同学非常友好。但全站也不能全都服务端渲染购物车页面和订单结算页面需要动态计算小计、合计、数量变化这个时候我就用Ajax来局部刷新。比如购物车里点击“数量加减”前端发起Ajax到后端更新购物车数量后端返回最新单价和总价前端用jQuery更新页面上的数字。这种局部刷新既展示了你的前后端交互能力又不用搞一个完整的前后端分离工程是性价比最高的方案。4.2 核心页面我踩过的交互坑先说商品详情页。页面里加购按钮是高频操作很多同学会写成整个表单提交刷新页面结果用户加一个商品页面就刷新一次体验很差。我改成点击加购后Ajax请求后端返回成功后在按钮旁边弹一个字“已加入购物车”的提示用户继续浏览商品也不受干扰体验一下就上来了。购物车页面最大的坑是全选和单选的勾选状态。我一开始设计的时候没有把勾选状态保存到数据库只是前端用了一个布尔变量控制结果用户刷新页面后所有勾选状态全部丢失下单商品数量对不上。最后我在购物车表里设计了checked字段每次勾选都同步到数据库结算时只取选中状态的购物车记录。这个设计不仅解决了刷新状态丢失问题也方便后端直接按选中状态生成订单。结算页面要展示订单明细、收货地址、支付金额三个信息块。地址选择建议做成单选列表点击某个地址卡片时高亮并记录地址ID避免用户输入。提交订单按钮要防止重复点击后端接口里判断如果正在处理中就提示“订单处理中请勿重复提交”前端按钮点击后立刻置灰双保险。后台管理页相对简单列表页用表格展示操作按钮用链接形式跳转。商品管理的关键功能是上架下架切换、库存修改、新增商品时上传图片。后台的图片上传要单独说前端表单用multipart/form-data提交后端用MultipartFile接收将图片保存到服务器本地磁盘目录然后数据库里只存访问路径。这里要额外配置一个虚拟路径映射把磁盘路径映射成/upload/**这种URL否则上传后图片无法在网页里访问。4.3 文件上传、日期与JSON的对接细节文件上传是我在实际开发中踩坑最多的点之一。SpringBoot默认的单次上传文件大小限制是1MB随便一张商品图片就会超限所以必须在配置里修改spring.servlet.multipart.max-file-size和max-request-size。我建议设置成10MB足够覆盖商品图场景。另外要注意上传目录如果不存在代码里要先创建目录再保存文件这个细节不处理直接保存会抛FileNotFoundException。日期格式也是一个容易翻车的地方。数据库里用datetime存储时间Java实体用LocalDateTime表示前端Thymeleaf直接显示时会出现一串英文字母格式的时间非常丑。我的处理方式是在实体类时间字段上统一加日期格式化注解指定pattern为yyyy-MM-dd HH:mm:ss这样无论JSON返回还是页面展示格式都是标准的。另外向数据库插入时间时统一用数据库默认值或者Java的LocalDateTime.now()避免手写字符串日期导致格式错误。前后端传JSON时还有一个经典问题前端用$.ajax提交JSON对象后端Controller方法参数不加RequestBody注解结果参数永远为null。很多同学对着这个bug查半天根本原因是没理解请求体里的JSON需要Spring的HttpMessageConverter去反序列化而RequestBody就是触发反序列化的关键。记得在所有接收JSON的接口方法参数上加RequestBody。5. 进度规划、打包部署与答辩准备5.1 五周完成一个可演示系统的节奏毕业设计最忌讳的就是前松后紧前面天天摸鱼最后熬夜赶工。我按自己的实际经验把整个项目拆成了五个阶段你照这个节奏走五周时间完全能完成一个可以演示的系统。第一周做需求分析和数据库设计。把所有页面原型用简单的线框图画出来把表结构和字段定下来验证逻辑关系后再开始写代码。这个阶段是最重要的因为表结构一旦定下来后面改动的代价极高。第二周搭后端基础框架和前台展示功能完成首页、商品列表、商品详情、注册登录这几个基础模块跑通“用户到商品”的浏览链路。第三周做购物车和订单核心链路这是系统的心脏完成加购、购物车管理、结算、下单、模拟支付目标是把一单完整的交易流程跑通。第四周做后台管理端包括商品管理、分类管理、订单管理、用户管理、数据统计。第五周整体联调测试、准备演示数据、打磨细节、打包部署、整理答辩材料。5.2 本地配置和服务器部署要点本地开发时配置文件要养成区分环境的好习惯。application-dev.yml放本地数据库连接application-prod.yml放部署环境连接主配置文件用spring.profiles.active指定启用哪个环境。这样本地测试和服务器部署不用来回改配置也避免了把本地数据库密码带到线上环境的尴尬。打包部署就一条命令mvn clean package。SpringBoot内置了Tomcat打包出来的jar文件直接用java -jar命令运行即可。部署到服务器时建议使用nohup命令让进程在后台运行同时把日志输出重定向到文件方便排查问题。启动命令大概长这样这里注意端口、数据库地址、账号密码要按照服务器环境修改。如果遇到jar包启动后访问页面样式全丢优先检查Thymeleaf模板里引用的静态资源路径是不是绝对路径。另外服务器上的MySQL时区如果和本地不一致会导致时间字段相差8小时解决方法是数据库连接串后面加serverTimezoneAsia/Shanghai参数并且保证服务器和数据库在同一时区。5.3 演示数据、答辩话术和高频问题演示的时候最尴尬的情况是页面上空空如也所有功能都点了一遍却看不出效果。一定要预置一套完整的演示数据至少十个分类、每个分类下五六个商品、三个左右的测试账号、两个用户账号里各有几个待支付和已发货的订单、几条评价记录。演示时按照“用户注册登录-浏览搜索-加购结算-模拟支付-后台发货-用户确认收货”这条主流程走一遍每一步都有数据支撑答辩效果比单纯讲PPT好一百倍。答辩高频问题基本集中在几个方向为什么选这个技术栈、数据库如何设计、事务怎么用、库存怎么防超卖、密码怎么加密、订单状态怎么流转、如果并发高怎么优化。这些问题在本题前面章节基本都有涉及建议提前把答案写成小纸条反复讲给自己听。被问到不会的也不要慌大方承认目前方案在什么场景下有什么局限然后说清楚如果未来改进会怎么改这个态度比强行编造答案加分。6. 常见问题与排查实录6.1 启动失败端口、依赖、静态资源我把实际开发中遇到频率最高的问题整理成一张速查表遇到直接对着排查故障现象可能原因排查办法项目启动报端口被占用8080被其他进程占用换个端口或在命令行查端口占用情况打包引用的依赖一直报红Maven依赖没下载完整关闭IDE重新导入或清理本地仓库依赖项目启动找不到数据源数据库地址或密码不对检查配置文件确认数据库服务已启动页面样式全部丢失静态资源被拦截器拦截在拦截器配置中放行/static、/css、/js路径接口返回404Controller路由不对或类没扫描到确认启动类位置Controller包必须在其子包下端口占用是最常见的启动问题。如果你本机之前跑过其他Web项目或者某个软件占用了8080窗口SpringBoot启动时就会直接报地址已被占用。最快的办法是直接在application.yml里改server.port换成8081或者8090省时省力。依赖爆红的问题通常发生在IDEA里Maven没有正确配置镜像源或者网络不稳定导致jar包下载不完整。操作上先尝试点击Maven面板的刷新按钮如果还不行就删除本地仓库里对应目录后重新下载。注意不要把整个本地仓库全删了里面有几百兆的公共依赖删了会重新下载很久。6.2 数据错乱乱码、时区、外键约束中文乱码是刚上手SpringBoot和MySQL时最常遇到的。排查思路按顺序来数据库连接串后面加characterEncodingutf8MySQL建库统一使用utf8mb4字符集响应结果如果乱码再检查是否缺少编码过滤器。我的经验是绝大多数乱码都出在连接串没有指定字符集加上之后基本就正常了。数据库时区问题前面提过这里再说一个容易忽略的操作。如果是在服务器上部署要注意服务器的系统时间是否准确否则定时任务生成的耗时统计、订单操作日志的时间全部错乱。建议部署后第一时间执行命令同步系统时间同时检查MySQL的time_zone配置。外键约束报错通常发生在我设计表关联太紧的时候。比如商品分类下已经有商品数据删除分类就会因为外键限制删除失败。我自己后期调整时把部分物理外键改成了逻辑外键即Java代码里维护关联关系而数据库层面不建立物理外键约束。删除数据时先处理子表数据再删除主表数据代码里严格控制顺序。这样既保留了一对多关系的语义又不会因为物理外键把操作锁死。6.3 订单链路Bug重复下单、库存回滚、状态不同步重复下单是电商项目的高频Bug。明明只想提交一次订单用户快速点击两下提交按钮结果生成了两笔订单库存也被扣了两次。根治方法从前端和后端两头一起堵。前端提交按钮在点击后立即禁用后端在创建订单之前判断是否已有相同用户同一批商品在途订单。虽然这不能100%阻止并发场景下的重复下单但至少把误操作频率降到了极低。库存回滚问题大多出在没有正确使用事务。如果你在Service方法上加了Transactional注解并且把扣库存和生成订单都放在这个事务方法里任何一步抛异常都会自动回滚。要重点检查的是异常是不是被自己catch住了。有些同学习惯在Service里把异常捕获并返回一个错误消息结果事务管理器根本没感知到异常自然就不会回滚。正确的做法是事务方法内部不要自己捕获业务异常吞掉让事务管理器处理或者在捕获后手动标记事务回滚。支付状态不同步是因为我在开发早期没有把“支付成功”和“更新状态”放在同一个逻辑里。后来我强调支付接口必须是幂等操作也就是说无论支付请求被调用几次订单状态都只会从待支付变成已支付一次。接口设计时先判断当前状态只有状态是待支付才执行支付逻辑如果已经不是待支付就直接返回“订单状态异常”避免了订单被重复支付确认。6.4 排查工具箱调试技巧方面我强烈建议把日志打好。在Service层的关键方法入口处打印入参在异常捕获处打印堆栈虽然看起来土但排查问题时效率极高。使用IDE的断点调试时重点在Controller进去时的参数、Service里查询结果是否为空、事务提交前后数据的变化三个位置打断点基本定位80%的问题。接口测试用调试工具非常方便不管是自测还是模拟前端提交请求都能直接调用后端接口查看返回结果。遇到前端传参不对导致后端报错用调试工具构造正确请求就能验证是不是前端的问题。我自己排查问题时还习惯看一下后端控制台日志里每次请求的SQL语句MyBatis-Plus默认会打印预处理参数一看SQL就知道是不是查询条件传错了。最后想把整个项目的经验浓缩成一句话毕业设计不求功能又多又炫把“商品浏览-加购-订单-支付-发货”这条核心交易链路做扎实把每个关键设计点吃透答辩的时候能逻辑清晰地讲出来就已经是一个很高质量的毕设了。我这个项目虽然也砍掉了很多花哨功能比如优惠券、秒杀、退款流程但核心链条完整每一步的为什么我都能说清楚这就是我最后顺利通过的关键。希望这篇复盘对正在做游戏周边商城的你有帮助如果踩坑踩到怀疑人生回来再看看这一节大概率能找到答案。
