做游戏零售平台这个项目前后折腾了大概两个月。SpringBoot Vue的组合是目前个人开发者和毕业设计里最常见的选型这套组合的好处在于SpringBoot把后端服务端的复杂度降得很低Vue则让前端交互页面的开发效率大幅提升两者拼在一起刚好能覆盖一个完整电商类网站的所有核心环节——用户登录、游戏商品展示、购物车、订单流转甚至支付回调。这篇博文会把我在做这个项目时的完整思路、技术选型的原因、核心代码逻辑、踩过的坑一次性整理出来计划用这个项目做毕业设计或者想自己练手完整全栈项目的人可以直接参考。1. 项目整体设计与技术选型1.1 核心需求拆解与功能边界游戏零售平台本质上是垂直领域的电商系统卖的是激活码、数字版游戏、Steam礼品卡这类虚拟商品。和普通电商比虚拟商品有几个关键差异不需要物流模块但需要处理激活码的唯一性和重复购买校验订单状态流转更简单但支付回调的并发处理不能马虎用户不需要收货地址但需要绑定邮箱或手机号用于接收卡密。我在需求分析阶段把功能拆成了两类前台用户端和后台管理端。用户端包含用户注册登录、首页游戏推荐、商品分类筛选、游戏详情展示、购物车管理、订单生成与支付、订单状态查询、个人资料修改。后台管理端包含游戏商品上架与下架、库存与激活码管理、订单管理、用户管理、数据看板。这个范围对于单人开发来说正好既覆盖了电商核心链路又不会让工作量失控。功能边界一定要提前划清楚。我在最开始也犯过贪多的毛病想把评论、社区、抽奖、积分都塞进去结果光表结构就设计了一周。后来冷静下来砍掉所有非核心功能把重心全部放在商品浏览到订单支付这条主线上开发效率立刻提上来了。对于毕设或练手项目我的建议是完成度比功能数量重要得多一条完整跑通的链路比十个半成品功能有说服力。1.2 为什么选SpringBootVue这套组合后端框架不是没有别的选择Python的Django、Flask甚至Node.js的Express都能做。但SpringBoot在这个场景下有几个不可替代的优势。第一生态成熟度极高从ORM到缓存到安全框架几乎每个技术点都有稳定的官方或社区方案遇到问题搜一下就能解决这对独立开发者非常重要。第二SpringBoot的自动配置机制让项目的启动和维护成本极低内嵌Tomcat让部署变成一条java -jar命令不用像传统SSH项目那样配置一堆XML。第三国内企业用人需求摆在那做完这个项目对找Java后端相关工作有直接帮助。Vue这边我用的是Vue 3 Vite组合。Vue 3的Composition API在组织业务代码时比Options API更灵活尤其是购物车这种涉及多个状态联动的场景用computed和watch处理起来非常顺手。Vite替代Webpack后的开发启动速度提升是肉眼可见的热更新基本在毫秒级极大改善了开发体验。加上Element Plus组件库后台管理界面基本不用怎么写样式就能有一个能看的UI。这套组合最大的价值是前后端完全分离。前端只需要关心页面渲染和用户交互通过HTTP接口拉取数据渲染完就完了后端只需要关心业务逻辑和数据持久化不掺和页面长什么样。这种职责划分清晰的分工让两个人协作开发时基本不用等对方也方便单人开发时分阶段推进——先把后端接口用Postman调通再写前端页面每一块都是可验证的。1.3 系统架构与项目目录规划项目采用了经典的前后端分离架构后端SpringBoot运行在8080端口前端Vue开发环境运行在5173端口通过代理转发解决跨域问题。数据库用MySQL 8.0Redis用于存储登录Token和热点数据缓存对象存储这块我直接用的MinIO用来存放游戏封面图和详情图。后端目录结构我是按分包分层来设计的controller层只管接收请求和参数校验service层处理业务逻辑mapper层用了MyBatis-Plus所以是mapper接口加XML操作数据库entity放实体类dto用于接口参数传递vo用于返回给前端的数据封装config放各种配置类utils放工具类exception统一处理异常。这个分层结构几乎成了SpringBoot项目的模板好处是每个类职责单一出了问题定位很快。前端目录结构按Vue官方推荐来划分views放页面组件components放可复用组件router放路由配置store用的Pinia放全局状态api目录统一管理接口请求utils放公共工具函数。前后端目录规划看起来是小事但项目代码量上来之后清晰的结构能省下大量找文件的时间。2. 后端核心实现与SpringBoot实战2.1 数据库设计核心表结构与字段说明游戏零售平台的核心表我设计了六张用户表、游戏商品表、游戏分类表、购物车表、订单表和订单明细表。虚拟商品的特殊之处在于激活码管理所以还额外有一张激活码表订单生成后把激活码关联到订单这样既能保证一个激活码只被一个订单使用又能防止超卖。用户表的核心字段包括id、username、password、nickname、email、phone、avatar、role、status、create_time。密码必须加密存储这里我用的BCrypt算法加密同一密码每次加密结果都不一致安全性比MD5直接存储强太多。role字段区分普通用户和管理员这个字段的校验不用太复杂前端隐藏管理员入口是一层后端接口做角色校验是更有力的保障。游戏商品表字段比较多核心有title、category_id、cover_image、description、price、original_price、stock、sales_count、status。price字段我用的是DECIMAL(10,2)类型这里有个经验价格计算千万不要用double浮点数精度问题会让你在订单金额计算时吃亏比如27.8加12.2得到40.00000000000001这种诡异结果。DECIMAL是精确计算代价是查询稍慢但订单金额这种场景必须精确。订单表和订单明细表是典型的一对多关系。订单表存订单号、用户id、总金额、支付方式、支付状态、订单状态、创建时间。订单号我生成规则是时间戳加用户id再加随机数虽然丑了点但保证唯一性够用。订单明细表存游戏id、游戏标题、价格、数量。激活码表主要字段是code、game_id、order_id默认NULL、status可用/已用。订单支付成功后用悲观锁查询该游戏可用激活码关联到订单号更新状态为已用。这样设计的好处是一个订单多款游戏时每款游戏都能精确分配对应的激活码。2.2 用户认证JWT方案与登录状态管理用户认证我采用的是JWTJSON Web Token方案。用户登录成功后后端生成一个Token返回给前端前端把Token存到localStorage里每次请求时在Authorization请求头带上后端通过拦截器校验Token的有效性。相比Session方案JWT的好处是天然支持前后端分离后端不需要存储登录状态服务器重启用户不用重新登录。JWT的结构是三段式Header.Payload.Signature。Header声明加密算法Payload存放用户基本信息比如userId和roleSignature用服务端密钥对前两段进行签名。关键点是密钥必须放在服务端配置文件里绝对不能泄露。Token里Payload部分不能放敏感信息密码之类的东西打死不能往里面放。生成Token的代码其实很直接用jjwt库的话核心就几行代码设置subject为userIdclaim里放role指定过期时间我设置的是2小时然后用一个密钥签名。拦截器才是重点需要排除放行的路径比如注册、登录、首页商品列表和详情接口这些是用户没登录也能访问的。剩下的接口统一检查Token解析失败或过期直接返回401状态码和一个统一的响应格式。这里踩过一个坑前端把Token放在localStorage里有个安全风险是XSS攻击可以拿到Token所以服务端在解析Token时我会检查来源同时在过滤器中加了对请求参数的转义处理。对于个人项目来说做到这个程度基本够用了也不用把Token换成HttpOnly Cookie那么复杂。2.3 商品、购物车与订单三大核心业务逻辑游戏商品模块相对简单主要是列表分页查询、按分类筛选、按关键词搜索、详情查看。这里用上了MyBatis-Plus的分页插件。分页插件配置其实就三步引入依赖、写一个MybatisPlusInterceptor的配置类、在mapper接口里传Page参数。配置完之后只需要在Service层new一个Page(current, size)把当前页和每页大小传进去再把查询条件写在LambdaQueryWrapper里MyBatis-Plus会自动生成带LIMIT的分页SQL还会同时查出总记录数返回分页结果。这个插件我用了很久唯一的坑是配置类的拦截器顺序分页插件要放在最后否则可能和其他注解型插件冲突。购物车业务是典型的分布式应用中“本地状态优先”的场景。我的实现思路是购物车数据跟着用户走用户加购后同步到后端表里这样换设备购物车数据不丢。表结构很简单id、user_id、game_id、quantity、create_time。唯一性约束建在user_id和game_id的联合索引上重复加购做的是数量累加。后端接口提供加购、改数量、删除、清空和查询列表接口前端购物车页面每次进入从后端拉取最新数据。订单这块是业务的硬骨头。生成订单我得同时处理三个核心问题用户余额或支付金额计算、库存扣减、激活码分配。我的方案是生成订单号后开启数据库事务先查询游戏状态和库存确认没问题后创建订单和订单明细同时扣减库存再尝试分配激活码。任何一个环节出错就回滚事务。这里最关键的逻辑是必须先锁库存再扣库存我会在查询游戏记录时加上for update的悲观锁否则在高并发下容易出现超卖。个人项目可能并发量不大但养成这个习惯能让代码更可靠。支付这部分因为涉及真实支付渠道需要有资质我在项目里做了模拟支付。前端调一个支付接口传入订单号后端模拟支付成功后把订单状态从待支付改为已支付同时发送激活码给用户。真实环境接微信支付或支付宝就是替换这个模拟接口核心订单状态机的逻辑是不变的。订单状态我定义了四种待支付、已支付、已取消、已退款对应不同业务操作。2.4 后端关键配置跨域、统一响应与全局异常处理跨域问题是前后端分离项目绕不开的第一道坎。浏览器安全策略默认不允许跨域请求开发环境下前端访问后端会报CORS错误。我采用的方案是在后端写一个CorsConfig配置类实现WebMvcConfigurer接口并重写addCorsMappings方法允许所有来源、所有请求头、所有方法访问同时支持携带凭证。生产环境把allowedOrigins改成具体域名不要用通配符。说实话这个配置网上教程一抓一大把但很多人搞不懂为什么要这么配其实核心就是让服务器在响应头里加上Access-Control-Allow-Origin相关的字段浏览器看到这个字段才愿意放行。统一响应格式也花了不少心思。我定义了Result类泛型设计包含code、message、data三个字段。code为200时表示成功非200表示各种业务错误。好处是前端能统一处理接口返回不用每个接口单独判断一堆乱七八糟的返回结构。配合全局异常处理器用RestControllerAdvice注解Controller里只管业务抛异常交给全局处理前端拿到的永远是结构一致的错误响应。全局过滤器这块我专门处理了两件事XSS攻击过滤和上传PDF文件的参数安全问题。XSS攻击的核心是往页面注入恶意脚本用户输入的内容在服务端输出HTML时如果没转义就危险了。我在全局过滤器里对请求参数做了HTML字符转义把尖括号、引号转成安全的实体字符从源头阻断XSS。有个细节是上传PDF文件时文件名和路径参数也要过一遍过滤否则攻击者可能利用特殊字符构造非法路径。这个过滤器会在请求到达Controller之前对parameterMap做一次清洗。3. 前端Vue实战与前后端联调3.1 Vue工程初始化与开发环境配置前端我用的Vue 3 Vite Pinia Vue Router 4 Element Plus这套组合在当前前端圈属于比较主流的选择。工程初始化直接用npm create vitelatest命令选Vue模板不需要自己从零配置Webpack。Vite的配置比Webpack省心太多一个vite.config.js基本能搞定全部。环境配置里有两个点必须处理好。第一个是开发代理我在vite.config.js里配置了server.proxy把/api开头的请求都代理到http://localhost:8080后端服务器。这样前端请求路径看起来是同源的浏览器不会拦截而且解决了跨域问题。代理配置好后前端开发时调后端接口就非常自然。第二个是环境变量我建了.env.development和.env.production两个文件分别配置不同的API基础路径上线时打包用生产环境变量开发时用开发环境变量。这个习惯我从第一个项目就开始用避免了每次部署都要手动改代码的尴尬。安装依赖这块npm install命令在安装慢或失败时最容易让人崩溃。这里有两个提高成功率的技巧一是用国内镜像源设置registry为npmmirror二是先安装核心依赖再安装UI库避免一次装一大堆导致依赖冲突报错。这个项目里npm install时遇到过Element Plus和Vite版本不兼容的问题解决思路是查官方文档确认支持的版本范围把package.json里的版本调整为兼容版本。3.2 Vue Router路由设计与页面导航游戏零售平台的页面路由我分成了两个层级前台用户端的路由和后台管理端的路由。用户端主页、商品列表页、商品详情页、购物车页、订单结算页为基本用户浏览路径后台管理端有Dashboard、商品管理、订单管理、用户管理页面。路由本身不复杂但有两个细节值得注意。第一个是路由懒加载。项目规模虽然不大但打包后JS文件一大首次打开页面就会很慢。解决办法是路由配置里使用动态import语法让每个页面组件单独打包成chunk访问到哪个路由才加载对应组件。这个优化对于大型前端项目是标配对个人项目而言也是好习惯。第二个是导航守卫。我在全局前置守卫里判断路由是否需要登录检查本地是否有Token以及Token是否过期未登录用户访问需登录页面时统一跳转到登录页。这样做了之后前端页面层面的访问控制就完整了后端接口还要再做一道校验进行兜底。动态路由这块我给管理员和普通用户分配了不同的可访问路由集合。在Pinia里存了当前用户的角色信息导航守卫里根据角色动态添加对应路由。原理不复杂但能体现对权限控制的思考深度。前端路由权限只是体验层面的控制真正的安全控制必须依赖后端接口的角色校验这个原则一定不要颠倒。3.3 Axios请求封装与前后端接口联调前端所有接口请求我统一通过Axios完成没有在每个组件里直接写请求代码而是封装了一个request工具函数。封装主要做了四件事创建Axios实例设置baseURL和请求超时请求拦截器里从localStorage读Token并加到请求头响应拦截器里统一处理错误状态码并弹出提示对业务响应数据做二次包装方便组件里直接拿data用。接口定义这块我在api目录下按功能模块拆分文件user.js管理用户相关接口、game.js管理商品接口、cart.js管理购物车接口、order.js管理订单接口。每个接口用函数导出参数直接传入。组件里调用时候只要import对应的接口函数然后await对应的返回结果就行。好处是接口路径集中管理后端接口一旦有调整只需改api目录对应文件的路径不用满项目去找。联调阶段最常见的幺蛾子是后端返回的数据结构和前端预期不一致。比如后端返回时间字段是一个长数字时间戳前端显示时需要格式化又比如分页接口返回字段名是records和total前端如果直接拿来绑定表格就需要先转换。我的经验是前后端联调之前先把接口文档约定好字段名、类型、层级都写清楚哪怕用个在线文档也好过人肉协调。我在这个项目里就吃了不少字段名不一致的亏后来老老实实用Apifox统一管理接口定义联调效率提升了不止一倍。3.4 购物车与订单流程的前端逻辑实现购物车页面在前端的状态管理上比较集中我选择了Pinia。状态里存着购物车列表、总数量和总金额三个核心状态。调用后端接口获取购物车数据后存到state里然后通过getter派生计算出总数量和总金额。当用户修改数量或删除商品时先调用后端接口更新数据接口成功后再同步更新本地state。这里的思路是以后端数据为准前端state只是一个缓存保证刷新页面后数据依然正确。订单结算页是购物车逻辑的自然延伸。用户在购物车勾选商品后点击结算跳转到订单确认页此时展示商品清单、计算金额、选择支付方式。确认后点击提交订单调后端接口生成订单前端拿到订单号后跳转支付页模拟支付完成后跳转到订单详情页。这一套流程走下来前后端的数据流转就全部打通了。前端有个人性化细节值得说说加购按钮的防重复点击。用户猛戳加购按钮时如果网络请求还没返回后端可能收到多个重复请求导致购物车里同一游戏数量翻倍。我用的方案是在按钮点击后立即把disabled状态置为true等接口返回后再恢复。这是很典型的性能体验优化类似的交互问题在个人项目里很容易被忽略但对用户感知影响很大。3.5 前后端联调的效率提升与调试技巧联调过程中浏览器开发者工具的Network面板是最常用的调试阵地。看到请求返回的状态码快速判断是前端写错了、后端报错了、还是网络问题。接口在Network里请求成功但页面没数据时八成是前端代码里解析数据的字段名对不上请求都发不出去时看看是不是代理配置问题或跨域问题。这些经验看着简单实际排查时能省好多时间。Vue Devtools插件调试时必备安装后浏览器扩展里多一个Vue标签页可以看到组件树、props、事件触发记录和Pinia状态变化。调试一个页面数据为什么不更新直接看响应式数据的变化远比console.log打印舒服。版本上要注意Devtools版本和Vue版本的匹配Vue 3项目装Vue 2的Devtools可能会出现面板不显示的问题。还有一个非常实用的工具是JSON格式化接口响应。后端接口返回的数据结构比较长的时候直接在Network面板选Preview标签页格式化查看不用复制到编辑器里再格式化。这套调试姿势配合Postman或Apifox先验证后端接口再从前端页面走全流程问题定位速度会快很多。4. 常见问题排查与性能优化实录4.1 跨域问题排查清单跨域问题在开发阶段出现频率极高排查思路其实很固定。先看浏览器控制台的报错信息如果包含CORS字样大概率就是跨域问题。此时先确认前端请求是否走了代理如果直接请求http://localhost:8080就是跨域请求应当走代理路径。再看后端是否配置了允许跨域的过滤器如果没有配置或配置了但没生效浏览器会拦截响应。这里有个排查深坑要单独说后端配置了跨域但前端请求还是报错并且请求头里带了自定义字段比如Authorization。这种情况大概率是后端跨域配置没有允许这个自定义请求头需要在allowedHeaders里把它加上。还有一点是开启凭证携带时allowedOrigins不能设为*必须指定具体域名否则浏览器同样会拦截。我把这些排查经验记在一个命名很直接的文档里现在再遇到跨域问题基本五分钟能定位。4.2 Docker部署SpringBoot和前端静态资源项目开发完成后的部署环节我选的是Docker方案。后端工程用Dockerfile构建镜像基础镜像用eclipse-temurin:8-jre把打包好的Jar复制进去暴露8080端口。数据库和Redis使用docker-compose编排同时把MySQL和Redis的持久化数据目录挂载到宿主机。这套方案最大的好处是环境一致性本地能把项目跑起来服务器上也一定行不再被环境差异折腾。前端部署用Nginx镜像构建时使用multi-stage策略。第一阶段用node镜像构建Vue工程生成dist目录第二阶段把dist目录里的文件复制到Nginx镜像的/usr/share/nginx/html。Nginx配置里需要将/api开头的请求反向代理到后端服务地址这个和开发环境很像只是代理目标变成了Docker网络的内部地址。前端打包时记住执行npm run build生成的产物在dist里别把源码直接部署上去。Docker部署的常见坑也不少。后端容器连不上数据库排查思路是先看容器是否在同一网络里再看数据库连接配置里的host是localhost还是容器名。如果用的localhost连接宿主机就要映射宿主机端口如果用容器间通信就用数据库服务名。另外SpringBoot健康检查依赖的东西没装齐全也会导致启动失败比如容器内没有bashactuator健康检查exec命令会异常改成http检查方案就稳了。4.3 性能优化从慢查询到热数据缓存个人项目的性能瓶颈通常不在硬件而在两个点SQL写得不讲究和热数据反复查库。首页的游戏列表和热门推荐用户刷一次就查一次数据库每次都是全表扫描加排序数据量大了响应时间就会明显变慢。优化第一步是给查询多的字段建立合适索引。游戏表的category_id、title的模糊查询字段、订单表的user_id、order_no都建了普通索引。第二步是慢查询日志的利用MySQL开启慢查询日志把执行时间超过1秒的SQL全部打印出来针对性分析执行计划。第三步是把热点数据放入Redis缓存我在项目里封装了一个缓存工具类查询商品列表时先查缓存缓存没有就查数据库并回填缓存设置过期时间五分钟。商品数据更新时删除相关缓存下次请求重新加载。购物车和用户信息的缓存也能做但实时性要求高不建议过度缓存。我见过一个同学把购物车也做缓存结果用户加购后购物车数据不一致排查半天才发现是缓存更新遗漏。经验之谈核心链路的写操作除非必要别强行套缓存一致性代价远大于性能收益。4.4 安全加固密码、Token与前端常见攻击个人项目的安全意识容易被忽略但上线后被攻击的教训却很痛。密码存储我采用BCrypt加密不用MD5或SHA这种可逆或碰撞风险的算法。前端密码在传输过程中为了安全可以考虑使用HTTPS如果开发环境没有证书至少别把明文密码写在日志里。登录接口加上简单的验证码逻辑防止被脚本暴力破解。Token安全方面Token过期时间不要太长项目里2小时为合理值同时前端在Axios拦截器捕获401时自动跳转登录页让用户重新登录获取新Token。还有一点是后端关键接口必须校验角色权限只校验是否登录是不够的管理端接口必须验证角色是否为管理员。这个校验我放在拦截器里统一处理。XSS和SQL注入也是重点。XSS方面全局过滤器对输入参数做转义SQL注入方面MyBatis-Plus的LambdaQueryWrapper预编译SQL自带了防注入能力避免了拼接SQL的危险。虽然个人项目没有专业安全团队但这些基础安全措施做全了系统的基本安全防线就有了。4.5 项目测试与验收清单项目完成后完整的自测流程至关重要。我整理了一份验收清单覆盖用户端和管理端两条业务线。用户端注册新用户、旧用户登录、登录状态失效跳转、浏览商品分类、搜索商品关键词、查看商品详情、加入购物车、修改数量、删除商品、提交订单、支付模拟、查看订单列表与详情。管理端登录管理员账号、添加新游戏、编辑游戏信息、上下架游戏、处理订单状态、查看用户列表。这个流程建议从头到尾走两遍以上第一遍正常情况验证主流程第二遍专门做一些边界操作空购物车提交订单、商品库存为零时下单、过期Token访问接口、重复提交同一订单。遇到任何异常就返回到对应模块解决。另一个建议是做一次简单的性能压测不用上专业工具用JMeter写个简单的并发请求模拟下单操作看订单接口在50个并发下是否会超时或导致库存扣减异常。如果超市和订单处理没问题说明核心链路的并发控制在合理范围内。结尾的个人感想这个项目做完之后我的体会是SpringBootVue这套组合是真的适合一个人或小团队独立完成一个完整产品。技术难度不在任何一个点上反而在怎么把所有环节串起来——从前端页面的用户交互到后端的业务逻辑再到数据库的数据一致性链路每一环都需要仔细想清楚。踩过的那些坑像跨域、分页插件配置、Docker容器网络、前端防重复点击单独拎出来看着不大但正是这些东西堆在一起构成了完整的开发经验。最后分享一个小建议如果你也打算做类似的电商或零售平台项目别急着写代码先花两三天把数据库表结构和前后端接口约定想清楚这比后面的编码时间更值钱。表结构一旦定了后续改起来牵扯面极大接口约定一致的直接结果是联调阶段基本不用返工。这个项目后续还可以扩展的方向不少比如接入真实支付渠道、增加游戏评论与评分模块、使用WebSocket做订单状态实时推送、用ELK收集分析用户行为日志。对我自己来说下一步准备把用户下单后平台自动发货激活码的流程做得更自动化尽量减少人工干预。这些方向后续有机会再写文章持续分享。