企业官网建设流程全解析

1. 这套系统到底在卖什么：游戏装备账号商城和普通电商的差异

我第一次看到“基于SpringBoot+Vue的游戏装备账号销售商城平台系统”这个题目时，第一反应是：这不就是个商城吗？注册、登录、商品列表、下单、支付、后台管理，照着常见电商项目改一改就行了。等真正把需求细拆了一遍，发现完全不是那么回事。游戏装备、账号这类商品是典型的虚拟商品，它的商品模型、库存逻辑、发货流程和实物电商差得非常远，很多同学把SpringBoot+Vue前后端分离商城做出来了，却卡在了“账号类商品怎么卖”这个业务逻辑上。

先说清楚这套系统定位。它本质上是一个虚拟商品交易平台，卖的是游戏账号、装备、皮肤、代练服务或者游戏币这类东西。和卖衣服卖手机不同，虚拟商品有几个特点：

1. 商品信息无法用一张普通的“SPU + 颜色尺码SKU”表完全描述。一个游戏账号要关联服务器、区服、角色等级、职业、装备评分、实名状态；一个游戏装备要关联游戏名称、大区、装备名称、属性词条、强化等级。字段不是固定几个，而是高度垂直。
2. 发货不靠物流。买家支付成功之后，平台要么把账号密码、卡密直接展示给买家，要么由客服人工改密后交付。所以订单状态不能照搬“待发货/已发货/已签收”，要设计成“待支付/支付成功/交付中/已完成/售后中”。
3. 库存和超卖问题比实物商品更尖锐。实物商品库存少了顶多延迟发货，账号类商品一个SKU往往就对应一个独立账号，卖出去之后如果不做锁定，同一时间被两个人下单，后续交付就乱套了。

所以在开始写代码之前，我强烈建议先把上面这点想清楚。我见过很多毕设项目把“游戏账号销售商城”做成了“披着游戏皮的普通书城”，后台商品管理里还是商品名、价格、简介、图片，完全没体现游戏场景。这样答辩时老师问一句“账号类商品和普通商品在数据库设计上有什么区别”，就很容易答不上来。

1.1 用户端和管理端应该拆成什么

这套系统至少要拆两个端：面向买家的商城端，和面向运营的管理后台。

商城端（C端）需要这些页面：首页商品推荐、商品分类列表、商品详情页、登录注册、购物车、订单确认页、订单列表、订单详情（包含交付信息）、个人中心。不需要做太复杂的社区功能，但商品详情页必须能把游戏账号的详细参数展示出来，比如大区、角色、等级、装备评分、价格历史。这里要注意一点：普通电商详情页是“图文介绍 + 规格选择”，游戏账号商品详情页更像“商品信息卡片 + 已售状态”。

管理后台（B端）需要这些功能：商品管理（上架、下架、审核）、分类管理、订单管理、交付管理、用户管理、轮播图管理、数据统计。很多同学把后台做成三四个菜单应付了事，但游戏商品平台最大的差异在“交付管理”上，你最好单独设计一个“发货记录”模块，记录每个订单的账号、密码、角色、区服，并且保留操作日志，这样才算把场景做透了。

另外还有一个常见需求是“卖家入驻”。不过大部分毕业设计不会真让C端用户直接发布商品，而是平台运营人员在后台上架。如果题目没有明确要求多用户店铺体系，我建议第一版做成“平台自营”模式，管理后台审核并上架商品，C端用户只负责购买。这样能省掉一整套店铺、卖家提现、商品审核的状态机，但核心的业务流程依然完整。

1.2 跑通主流程：从注册到交付

一个最简可用的业务闭环是这样的：

• 用户注册登录，浏览首页商品。
• 点击商品详情，加入购物车或立即购买。
• 下单时选择购买数量（账号类商品通常只能是1，因为一个账号是唯一的一件货）。
• 模拟支付或接入支付平台，订单状态变为“已支付”。
• 系统生成交付信息，把账号、密码、区服信息写入订单交付记录。
• 买家在订单详情里查看信息，点击确认收货，订单完成。
• 如果出现问题，发起售后，管理员介入。

这个流程看起来不复杂，但里面涉及数据一致性、幂等、库存锁、状态流转，是后端大头。很多项目跑不起来或者答辩演示翻车，往往就挂在第二步到第五步之间。

2. 技术选型的取舍：为什么是SpringBoot+Vue而不是其他组合

“SpringBoot+Vue”是目前Java毕设里最稳妥、也最适合前后端分离实战的组合。我自己的习惯是：不用纠结是不是最新版本，关键是团队能不能把环境跑通、周围反馈资料够不够多。SpringBoot的生态足够成熟，MyBatis-Plus帮你把单表CRUD省掉大半，Spring Security或简单拦截器做登录校验，Redis处理缓存和幂等，这套组合应付毕业设计绰绰有余。前端用Vue，不是因为Vue比React“更好”，而是Vue的中文资料、组件库集成、学习曲线更适合大多数同学的实际情况。

前端我用的是Vue3 + Vite + Element Plus + Axios + Vue Router。你可能看到很多老项目还在用Vue2 + Vue CLI，但新写代码建议直接Vue3。Vite启动快，Element Plus组件覆盖后台管理场景，表格、弹窗、表单校验基本开箱即用，不用再自己造轮子。

2.1 后端版本选择：SpringBoot 2.7 还是 3.x

这里必须说一个很现实的问题。很多同学打开Spring Boot官网看到最新版本已经到3.x，就无脑选了最新版，结果在配置依赖时发现javax变成jakarta，部分第三方库还没适配，最后一天到晚在调环境。如果你本地JDK是8，我建议直接SpringBoot 2.7.x；如果你JDK是17以上，可以选3.x，但要做好部分代码写法变化的心理准备。

SpringBoot 2.7 + JDK8这套组合，和MyBatis-Plus、MySQL驱动、JWT这些依赖兼容最稳定，教程也最多。不是说新版本不好，而是我们做系统、写毕业设计，追求的是用最少的时间把业务跑通，而不是去帮框架适配踩坑。

后端依赖里我认为这几个是必不可少的：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、jjwt、spring-boot-starter-data-redis。至于Spring Security，如果你对过滤器、认证流程还不熟，可以在第一个版本里先用拦截器实现JWT登录校验，把安全控制做简单但完整。等核心流程跑通了，再决定要不要换成Spring Security。很多教程一开始就上Spring Security，容易把人绕晕。

2.2 前端工程化的目录结构

前端不要把所有代码堆在App.vue里。我用过比较顺手的项目结构是这样：

• src/api放所有请求接口的封装，每个模块一个文件，比如product.js、order.js。
• src/router统一配置路由，加全局前置守卫判断登录状态。
• src/views放页面组件，按用户端和管理端拆分两个目录。
• src/store用Pinia管理用户信息、购物车数量、权限状态。
• src/utils放axios实例、token处理、时间格式化等公共工具。

这套结构的价值在于：前后端分离项目中，接口调用逻辑如果散落在每个页面里，后期联调会非常痛苦。把所有API收敛到一个文件里，后端改个字段，你只需要到对应模块里找一次。

2.3 分清“重后端”和“重前端”的模块

我的实践体会是，这套系统最核心的业务逻辑都应该放在后端，不要依赖前端判断。比如“库存是否足够”“用户是否重复下单”“支付回调是否处理过”“订单状态能否从当前状态流转到下一状态”，这些都必须由后端校验。前端的作用是把页面做好看、交互做顺畅，但绝对不能只靠前端隐藏按钮来控制操作。

所以到写代码的时候，我会先想清楚后端接口的边界。每个接口只做一件事，比如创建订单接口就只负责创建订单，不要在里面顺手把支付也调了；支付回调处理要单独一个接口；确认收货又是一个接口。这样调试的时候定位问题最快。

3. 核心数据模型与功能模块拆解

整个系统能不能体现“游戏商城”的特点，数据库表设计是核心。泛泛的“product表”谁都会建，但一个能支持账号、装备、卡密多种虚拟商品形态的表结构，才是这套系统的价值所在。

3.1 商品表和SKU表怎么设计

我建议做成“商品主表 + 商品扩展表”的组合。商品主表只存公共字段：商品名称、分类ID、封面图、简介、销售状态、创建时间。然后根据商品类型，用一张扩展表保存游戏商品特有的字段。

如果你不愿意做动态字段，最稳的方案是分成“账号商品表”和“装备商品表”，公共字段放主表，差异字段放子表。账号商品表至少要有：游戏名称、服务器、角色名称、角色等级、职业、账号单价、账号描述、是否支持改密。装备商品表至少要有：游戏名称、大区、装备名称、装备类型、属性说明、强化等级。

但实际操作中还会有“同一个账号商品，卖家上传了多个同一服务器下的角色”的情况。这种时候用“商品表 + SKU表”更合适：

如果你是做毕设，我强烈建议至少把product和product_sku分开。这样“商品详情页”才能展示出游戏玩家真正关心的参数，而不是只显示一段纯文本简介。

3.2 库存扣减：防止超卖的实际做法

虚拟商品一个SKU往往代表唯一一件货，所以库存扣减比普通商城更严格。创建订单时必须“预占库存”，订单超时未支付再回补库存。最常用的做法是乐观锁更新，直接在SQL语句里判断库存：

UPDATE product_sku SET stock = stock - 1 WHERE id = #{skuId} AND stock >= 1;

然后在Java里判断受影响行数，如果返回0就说明库存不足：

@Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateRequest request) { int rows = productSkuMapper.deductStock(request.getSkuId()); if (rows == 0) { throw new BizException("该商品已被其他用户锁定，请刷新页面"); } // 生成订单号和订单记录 // 创建支付流水 }

还有一个容易忽略的点：SQL里的stock >= 1不能丢。很多人写set stock = stock - 1 where id = ?，在高并发下两个请求同时读到库存1，就会变成负数。虽然毕业设计并发量不高，但答辩老师很爱问这个点，你主动在代码里使用条件更新，会显得你真的理解超卖问题。

订单状态流转建议统一用一个状态枚举来管理：

在每一处更新状态的Service方法里，都加上“当前状态校验”，不要让订单能随意从“已完成”跳回“待支付”。用乐观锁或者update ... where status = 0这样的写法都可以，关键是状态不能乱跳。

3.3 订单与支付回滚

虚拟商品交付涉及到钱，所以“支付成功”这个事件最好由后端主动查证，而不是前端传一个“我支付成功了”的布尔值。如果只是模拟支付，也建议做一个支付流水表，记录每次支付的订单号、支付方式、支付金额、回调时间、回调状态。后端接支付回调时，要按“订单号 + 支付流水号”做幂等。哪怕同一个回调推送了三次，也最多只会把订单状态改一次。

生成订单号时不要直接用数据库自增ID，可以用“时间戳 + 随机数 + 用户ID后四位”这种格式，既方便看，也能防止被人遍历订单。示例：

String orderNo = "G" + System.currentTimeMillis() + String.format("%04d", userId % 10000) + RandomUtil.randomNumbers(4);

3.4 交付落库：账号密码不能直接到处放

买家支付后，系统要把交付信息展示给买家。交付信息表建议单独建，不要直接塞在订单表里。字段包括：订单ID、账号、密码、区服、角色名、交付说明、交付时间、操作人。密码这类敏感信息在后台列表中建议做掩码显示，比如只显示前两位和后两位，后台管理员如果需要查看完整密码，再点击详情查看。这是个小细节，但在实际交付场景里很重要，演示时也能体现你的系统有安全意识。

4. 前后端分离联调里的真实翻车点

前后端分离项目最难的不是写业务，而是联调和部署。很多同学单测后端接口一切正常，前端页面一调就全是跨域、404、401。这里我把踩过的坑集中总结一下，特别是几个和这套系统强相关的问题。

4.1 跨域配置：一个CORS配置引发的连锁问题

前端开发服务器默认跑在http://localhost:5173，后端跑在http://localhost:8080，浏览器会拦截跨域请求。最常见的报错是“Access-Control-Allow-Origin”相关提示。SpringBoot里最简单的做法是写一个全局CORS配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意这里要用allowedOriginPatterns("*")而不是allowedOrigins("*")，因为allowCredentials(true)时，allowedOrigins("*")会被浏览器拒绝。这个点特别容易踩。如果后端加了Spring Security，拦截器或过滤器也要确保对OPTIONS请求直接放行，否则预检请求被拦截，前端就会看到一堆莫名其妙的跨域错。

4.2 按钮重复提交：从下单接口开始防

游戏账号秒杀、抢购场景里，买家连续点十次下单，就会创建十个重复订单。这种问题不仅要靠前端“点击后置灰”解决，后端一定要做幂等。

前端最直接的办法是提交后立刻把按钮置灰，但用户刷新页面、网络重试等情况，前端控制没那么可靠。后端常用的做法是：前端在发起下单请求时生成一个requestId，后端把这个ID作为唯一键放到Redis里，设置几分钟过期；如果同一个ID第二次进来，直接拒绝。

使用Redis的setIfAbsent是最轻量的实现：

@PostMapping("/order/create") public Result<Long> createOrder(@RequestHeader("Idempotent-Key") String requestId, @RequestBody OrderCreateRequest request) { Boolean first = stringRedisTemplate.opsForValue() .setIfAbsent("order:submit:" + requestId, "1", Duration.ofMinutes(10)); if (Boolean.FALSE.equals(first)) { return Result.error("请勿重复提交"); } // 正常创建订单 }

当然，如果项目里没有Redis，也可以用数据库唯一索引。给订单表加一个biz_request_id字段，建立唯一索引，如果重复插入会抛DuplicateKeyException，捕获后返回“请勿重复提交”。两种方案都行，但Redis方案更贴近真实生产环境，也更好解释。

4.3 图片上传：本地目录还是MinIO

游戏商品需要封面图、详情图、账号截图，这就要做图片上传。最简单的是把文件保存在本地上传目录，然后把静态资源映射到SpringBoot：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/"); }

但这种方案在打包部署后经常出问题，因为当前目录不一定可写。如果要体现实用性，建议引入MinIO。MinIO是私有化部署的对象存储服务，很多中小项目拿它当文件服务器用。核心依赖：

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.5.7</version> </dependency>

上传接口的核心逻辑：

String objectName = UUID.randomUUID().toString().replace("-", "") + "." + FilenameUtils.getExtension(file.getOriginalFilename()); minioClient.putObject( PutObjectArgs.builder() .bucket("game-mall") .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return "http://你的MinIO地址/game-mall/" + objectName;

MinIO对象名必须唯一，所以不能用原始文件名直接存，否则两个人传同一张a.jpg会互相覆盖。我习惯用UUID重命名。注意如果是学校内网部署，MinIO的地址要写前端能访问到的IP或域名，不要写localhost，否则前端页面里图片全部打不开。

4.4 Vue打包以后怎么进SpringBoot部署

开发联调完成后要部署，这里有两个方案。

方案一：前后端完全分离部署。前端把Vue项目build到dist目录，放到Nginx下，Nginx同时代理/api到后端8080端口。这样做最正规，也最接近生产环境。Nginx配置参考：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

方案二：把Vue打包出来的dist目录复制到SpringBoot的src/main/resources/static下，然后重新打包成单个jar。这个方案适合老师演示，一个jar跑起来就能访问页面，但有两个坑：一是注意后端接口路径和前端请求路径不能冲突，比如后端接口不要叫/index.html；二是如果前端使用了Vue Router的history模式，刷新页面时会404，这个方案下通常只能改成hash模式，或者在后端加一个静态资源降级转发。新手最简单的方法是Vue Router用createWebHashHistory，把地址变成带#/的格式，部署刷新就不会出问题。

5. 调试与验收的实战心得

系统做完了，能不能稳定演示又是一个坎。这里讲几个我调试游戏商城系统时常用的方法，以及一些类似“前端报错还是后端报错”的判断经验。

5.1 一个接口请求挂了，先看Network再查日志

前后端分离项目最大的一个错觉是：前端页面报错，就是前端的问题；后端日志报错，才是后端的问题。实际上很多问题发生在请求链路上。我的习惯是先把浏览器F12打开，看Network面板：

• 请求状态是CORS error，说明跨域配置有问题。
• 状态码是404，说明URL路径写错了，或者Nginx代理转发路径不对。
• 状态码是401，说明token没带，或者token过期。
• 状态码是500，再看后端日志，同时看接口返回的message是否友好。

如果Network里请求已经发出去并且有了红色状态，再去后端控制台看异常栈。如果请求压根没发出去，那大概率是前端axios封装、路由守卫拦截了请求，或者请求参数没拼对。这个“先看Network，再查日志”的顺序非常有用，能省掉大量无效排查时间。

后端日志建议打开MyBatis的SQL打印，这样你一眼就能看到每次更新库存、查询商品实际执行的SQL是什么，排查“为什么查出来是空”“为什么库存没减成功”这类问题：

mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

5.2 最容易在答辩演示时翻车的三个点

第一，支付环节没有做模拟兜底。如果现场演示时无法真正拉起支付，要提前准备一个“后台手动标记支付成功”的功能，或者一个免支付的测试开关，演示时一键把订单置为已支付。否则线上不能支付，整个交付流程就走不下去。

第二，刷新页面之后登录态丢失。Vue项目部署后，用户登录后一刷新就跳回登录页，多半是Vuex/Pinia里的状态没有持久化。解决方案是把用户token和用户信息同时存到localStorage或sessionStorage，在应用初始化时恢复登录状态。注意JWT失效时间要合理，不要太短，比如设置24小时，否则演示中途过期就尴尬了。

第三，数据库里的时间字段全是1970-01-01。很多同学建表时用了datetime默认值，但插入时没有填值，数据库又没设置CURRENT_TIMESTAMP，造成页面显示错误。建议建表时：

create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'

这样就不用每次插入都手动塞时间了。

5.3 关于说明文档和毕业设计材料的建议

这套系统除了代码，最好再准备一份项目说明文档，里面说清楚：系统总体架构图、技术选型理由、数据库设计ER图、核心接口列表、部署步骤、功能测试用例。不是单纯为了交材料，而是这些整理过程会逼你把系统逻辑重新梳一遍。

我在写这类项目文档时，一般会把核心流程拆成“用户为什么买、系统怎么卖、订单怎么交付、异常怎么处理”四个问题来讲。答辩老师最喜欢问的就是，“你这个系统遇到一个用户买完不支付怎么办”“两个用户同时买一个账号怎么办”“订单状态怎么保证不会变乱”。你只要能把这三个问题回答上来，哪怕界面朴素一点，项目的完成度也会被认可。

代码之外，我也建议不要直接把别人的完整源码交上去当自己的成果。你至少要能独立把核心的表结构、订单状态机、库存扣减逻辑讲清楚。这种能力的价值，比一个写在简历里但说不清原理的项目名字重要得多。

如果你准备从零开始做这套系统，我的最优先建议是先跑通一条主链路：用户注册登录、管理员上架一个游戏账号、用户下单支付、系统自动交付、用户确认收货。先把这条链路跑通，再去做购物车、后台统计、图片上传、权限细分这些锦上添花的东西。这条主链路涉及的每个环节都有坑，但也正是这套系统最值得写进毕业设计里的部分。