企业官网建设流程全解析

每年到这个时间点，都有不少学弟学妹拿着“基于Spring Boot的游戏售卖商城系统”来问我怎么跑起来、怎么讲给答辩老师听。有的手里只有一份 hello 级别的代码，有的买的是带完整文档和远程调试的整套源码，进度差距很大，但核心诉求都一样：把这个项目变成自己真能讲清楚、跑得动的毕业设计或课程设计。我这两年带的项目里，游戏售卖商城系统算是电商类毕设里性价比很高的一类：方向明确、业务闭环完整、技术点覆盖Spring Boot几乎所有的主流组合，而且演示效果直观，做出来就是商品列表、购物车、订单、支付、后台管理一条龙。这篇文章我不对着PPT念，按我实际带项目的顺序，把这些东西拆开讲一遍：从需求边界、核心技术、数据库设计到最后的部署、远程调试和答辩准备，尽量让零基础的人也能一步步把项目吃透。

1. 项目整体拆解：这到底是个什么系统

1.1 需求边界：游戏商城和普通电商最大的区别是虚拟交付

先别着急写代码，很多同学拿到题目第一反应是“我有Spring Boot基础，直接上手做”，结果做着做着发现功能多到失控。游戏售卖商城本质上还是一个电商系统，但它和传统卖衣服、卖数码产品的商城有一个很关键的区别：交付物是虚拟商品。

这里的虚拟商品包括游戏激活码、Steam钱包码、充值卡密、游戏账号、DLC兑换码等等。虚拟商品意味着没有物流、没有运费、没有退货地址，核心流程从“用户下单 -> 发货 -> 物流签收”变成了“用户下单 -> 支付成功 -> 系统自动发送卡密”。这个流程上的差异，直接影响数据库设计和代码逻辑：你必须有一张卡密/密钥表，商品库存不是某个整数，而是可售卡密的数量；订单支付成功后要触发自动发货，而不是靠人工点发货按钮。

从角色上说，我建议划分三类：游客、注册用户、管理员。游客只能浏览商品和搜索；注册用户可以加购物车、下单、支付、查看订单和卡密；管理员负责商品管理、分类管理、卡密导入、订单处理和统计报表。这个权限边界不要做得太复杂，也不需要引入过于细粒度的RBAC权限模型，因为毕业设计答辩时老师更看重你能不能把核心业务讲清楚，而不是你的权限表有多花哨。

功能模块上，我比较推荐这样一个稳定版本：

• 前台：商品分类、商品详情、搜索、购物车、下单结算、支付宝沙箱支付、个人中心、卡密查看
• 后台：登录、商品CRUD、分类管理、卡密批量导入、订单列表、发货重试、基础统计
• 公共能力：文件上传（图片）、Redis缓存、统一异常处理、登录拦截

有些同学想加秒杀、优惠券、积分商城这些花活，我的建议是先做主线，主线稳了再考虑。主线就是“用户能看、能买、能付、能收到卡密”，这条链路一旦通了，其他都是点缀。

1.2 技术选型：为什么是Spring Boot单体和Vue前后端分离

很多人在技术选型上纠结，要不要上微服务？网关、注册中心、OpenFeign、分布式事务一套下来，看起来特别高大上。但从毕业设计的角度看，我非常不建议这么干。游戏售卖商城的核心业务量根本到不了微服务这个量级，微服务带来的部署复杂度、环境问题、日志排查成本，足够让一个零基础的初学者在答辩前夜崩掉。面试官/答辩老师听到你用单体架构，完全不会扣分，只要你能说清楚单体在什么阶段够用、什么阶段需要拆分，就已经很加分了。

单体应用选Spring Boot，核心原因是它的自动装配机制大幅降低了配置成本。你引入spring-boot-starter-web，内嵌Tomcat就自动就绪；引入spring-boot-starter-data-redis，RedisTemplate就能用；引入mybatis-plus-boot-starter，Mapper扫描就帮你搞定。你需要关心的只是业务本身，而这正是毕设阶段最该做的事。

前端我推荐Vue3 + Vite + Element Plus，原因有两个：一是中文资料多，遇到问题随便搜就有答案；二是Vue的工程化结构清楚，打包后就是纯静态文件，放在Nginx下既能单独部署，也能和后端做反向代理，方便演示。如果你完全不会前端，用Vue2 + Element UI也没问题，但我不建议再学React，因为毕设的精力应该放在后端核心逻辑上。

后端持久层框架，我推荐MyBatis-Plus而不是JPA。MyBatis-Plus的分页插件、LambdaQueryWrapper、代码生成器对毕设效率提升很大，而且SQL是显式可控的，出了问题方便排查。JPA虽然写起来更“面向对象”，但对数据库表结构的隐式控制较多，初学者在联调时容易因为“为什么自动建表了”“为什么N+1查询”这些问题翻车。

1.3 项目目录结构：提前把架子搭好，后面开发少踩坑

拿到源码或者自己新建项目时，我建议先看清包结构再启动。一个适合毕设的包结构一般是：

com.example.gamestore ├── controller # 接口层 ├── service # 业务层，接口+实现 ├── mapper # MyBatis-Plus Mapper ├── entity # 数据库实体类 ├── dto # 前端传参对象 ├── vo # 接口返回对象 ├── config # 配置类，如Redis、拦截器、跨域 ├── common # 统一返回、异常、常量

这个结构的核心思路是“每一层只做自己的事”：Controller只做参数接收和结果包装，Service只做业务逻辑，Mapper只做数据访问。很多同学图省事把SQL写在Controller里，当时觉得快，后面排查一个订单状态的bug能把整个文件翻三遍，这就是给自己埋坑。有一个我反复强调的细节：实体类不要直接返回给前端。用单独的VO对象去包装，比如实体里有一个冗余字段cardPass，如果你直接返回实体，用户信息可能串出去，这不是危言耸听。

2. 核心技术点：从鉴权到支付，每一环都是答辩点

2.1 登录认证：为什么用JWT而不是Session

这是答辩老师最爱问的点。你用Spring Boot做前后端分离，登录状态不能再依赖后端Session里的Cookie，因为前端是单独部署的，接口请求来自不同端口或域名，Cookie跨域问题很麻烦。JWT（JSON Web Token）把用户信息加密放在token里，后端不存session，天然适合前后端分离。

我常用的方案是：Spring Boot + JWT + 拦截器，不把Spring Security全家桶全部引入，因为对本项目来说Security的过滤器链过于复杂，配置写错一个验证规则，排查成本很高。核心登录流程是：

1. 用户提交用户名和密码，后端校验密码。
2. 校验通过后生成JWT，payload里放userId、username、过期时间。
3. 前端把token存在localStorage，每次请求在axios请求拦截器里加Authorization: Bearer xxx。
4. 后端写一个LoginInterceptor，从请求头解析token，解析成功就把userId放到ThreadLocal里，解析失败返回401。

这里要说一个很多初学者的误区：JWT是“无状态的”，不代表“无法主动失效”。如果你的业务有“修改密码后让旧token失效”的需求，需要在Redis里维护一个token版本号或黑名单。毕设阶段不一定要做到，但答辩时如果被问到“JWT被偷了怎么办”，你能答出“用Redis黑名单或缩短过期时间”，这个深度就足够了。

密码存储也是个低分陷阱。数据库里的用户密码不要用MD5直接存，MD5撞库很容易被反查。用BCryptPasswordEncoder，同一个密码每次加密结果都不同，自带的matches方法校验，成本低但说服力强。

2.2 商品缓存与购物车：Redis怎么用才不容易出错

Redis在这个项目里至少承担三个职责：商品详情缓存、购物车临时数据、防止商品超卖的分布式锁。这三个职责的写法截然不同。

商品详情缓存很简单，用一个StringRedisTemplate存JSON就行，key类似product:detail:{id}，查询时先查缓存，命中就直接返回，没命中查数据库再回写缓存。这里需要处理缓存一致性：后台修改商品信息后，不要只更新数据库，要把对应的缓存key删掉，否则用户看到的是旧价格，这比不缓存还糟糕。我实际带项目时遇到过好几次“改完商品价格，前端怎么刷新都不变”的坑，最后发现就是缓存没删。

购物车我用Redis的Hash结构存，field是商品ID，value是数量，key是cart:userId，这样能尽量减少数据库压力。不过要注意：如果要求“未登录也能加购物车”，那还得给游客生成一个临时标记，购物车数据合并到登录用户头上，这个逻辑比较麻烦。毕设我的建议是明确要求“登录后加购物车”，省掉一半的边界处理。

最后是防止超卖。虚拟商品虽然库存通常比实物大，但秒杀或一次性导入500个卡密时，多人同时下单就可能超卖。最核心的兜底是数据库原子扣减SQL：

UPDATE game_sku SET stock = stock - 1 WHERE sku_id = #{skuId} AND stock > 0

用stock > 0作为条件，让数据库来保证不出现负数库存。在高并发场景下再配合Redis的setnx做分布式锁。我特别提醒：不要用Java代码里“先select库存再update”的方式，因为两个请求都读到库存=1，然后都执行update，库存会变成-1，这在并发场景下是必现的。这不是高端知识点，但答辩时能把这个差异讲清楚，绝对是个加分项。

2.3 支付宝沙箱支付与订单状态机

游戏售卖商城不带真实支付，演示用支付宝沙箱就够了。沙箱的本质是模拟环境，你用自己的支付宝账号申请一个沙箱应用，拿到开发者密钥和沙箱账号，付款时输入的是沙箱账号和密码，钱不会真实扣款，非常适合答辩演示。

接入流程大致是：支付宝开放平台 -> 沙箱应用 -> 配置应用网关和回调地址 -> 下载官方SDK -> 后端封装支付接口。前端点击“去支付”时，后端生成支付宝表单返回给前端，前端自动提交跳转到支付宝沙箱收银台；用户付款后，支付宝会异步通知你的回调接口，你在回调里验签、核对订单金额和商户订单号，确认没问题后把订单状态改成“已支付”。

订单状态机是这里的灵魂。我一般定义六种状态：

状态流转要遵守单向原则：待支付可以取消或支付，已支付才能发货，已发货才能完成。千万不要让代码里出现“从待支付直接跳已完成”这种旁路。支付成功后自动发货的逻辑可以做成同步调用，也可以把任务丢到线程池或消息队列里异步处理。毕设建议用Spring自带的@Async做一个简单的异步发放，既能体现业务完整性，又不至于引入一套MQ导致部署难度上升。

还有一个容易漏掉的细节：金额计算必须用BigDecimal或数据库的decimal，绝不能用float/double。0.1加0.2在二进制里不是等于0.3，用浮点算金额早晚会因为精度问题被老师抓出bug。支付回调里也一定要再次校验金额，不能只认订单号，否则存在理论上的安全问题。

3. 数据库设计：把虚拟商品的账算清楚

3.1 核心表结构：从用户到卡密，一张都不能少

数据库是毕设项目的脸面，老师不一定看你的代码，但十有八九会看你的ER图。游戏售卖商城的核心表我建议至少包含这几张：用户表、分类表、商品表、卡密表、购物车表、订单表、订单明细表、支付流水表。

用户表字段比较简单：id、username、password、nickname、phone、avatar、create_time。商品表要区分普通字段和库存字段：标题、封面图、价格、原价、分类ID、销量、状态（上架/下架）、库存。这里的库存不要理解成普通数字，应该理解成“当前可售卡密数量”。

卡密表是最容易设计错的。很多新手会把卡密直接设计成商品表的一个字符串字段，例如card_list VARCHAR(1000)，这样当然也能演示，但一旦一个商品有几百个卡密，这个字段会变成一个巨大的文本，后来查哪个卡密卖过、哪个没卖过，会非常痛苦。正确的做法是单独一张game_key表：

CREATE TABLE `game_key` ( `id` bigint NOT NULL AUTO_INCREMENT, `product_id` bigint NOT NULL COMMENT '商品ID', `card_no` varchar(255) NOT NULL COMMENT '卡密内容', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0未售 1已售', `order_id` bigint DEFAULT NULL COMMENT '售出后绑定订单ID', `sell_time` datetime DEFAULT NULL COMMENT '售出时间', PRIMARY KEY (`id`), KEY `idx_product_status` (`product_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='卡密表';

上面这个表的关键在于给product_id和status建了联合索引。用户下单支付成功后，代码先从卡密表查到一条status=0的记录并原子更新为1，然后把卡密内容填到订单明细里。这样“卖出去哪个卡密”永远有据可查。

订单表我建议把订单号和用户ID建唯一索引，订单号要保证全局唯一，绝对不能由数据库自增ID直接代替展示给用户。生成订单号的常用方式是：时间戳 + 用户ID + 随机数，或者在数据库层面用一个单独的流水号表。无论用哪种，都要保证并发下不重复。

3.2 防超卖、幂等与事务边界

数据库设计除了表结构，更重要的是约束。防超卖最终靠的是SQL语义而不是代码判断，前面已经讲过原子UPDATE。这里再补充一个做法：在订单明细表里加一个game_key_id字段，并建立唯一索引。这样即使逻辑出现并发抽风，两个请求同时发放同一个卡密，数据库也会因为唯一索引冲突拒绝其中一条，给我们留出报错和重试的机会，这是很实用的兜底策略。

支付幂等也靠唯一索引。支付流水表的trade_no（支付宝交易号）和order_no都建唯一索引，每次异步通知进来，先尝试插入流水，如果插入成功说明是第一次处理；如果插入冲突，说明是重复通知，直接返回成功不再处理业务。这套“先查后改”和“唯一约束兜底”的组合我强烈推荐，因为毕业设计中80%的支付bug都来自“回调被重复调用后，用户的卡密被发了两次”。

事务这里我要提个醒：@Transactional不是放在类上就万事大吉。它默认只对RuntimeException回滚，如果方法内部catch了异常没抛出，事务是不会回滚的。另外，尽量不要把耗时操作放在事务里，比如给用户发送卡密邮件、调用支付宝查询接口，这些可以放到事务提交后再执行，否则数据库连接会被长时间占用。一个有水平的开发者，会很自然地在答辩时说“我用事务保证订单和扣库存的一致性，把纯网络操作放到事务外面”。

4. 从零启动到上线：环境搭建、联调、部署与远程调试

4.1 本地启动的正确姿势：版本对齐比什么都重要

我带项目这么多年，发现80%的“跑不起来”根本不是代码问题，而是环境版本和配置对不上。这个项目我推荐一套稳定的组合：JDK 8 + Spring Boot 2.7.x + MySQL 5.7/8.0 + Redis 6.x + Node 16/18 + Vue3。不要贪新用Spring Boot 3.0以上，除非你已经熟到能自己解决Jakarta命名空间迁移，否则网上资料大概率基于2.x，你抄代码时踩坑成本会低很多。

拿到源码后不要急着双击启动，先看三个文件：pom.xml、application.yml（或properties）、init.sql（数据库脚本）。pom里确认依赖完整，yml里确认数据源、Redis、文件上传路径等配置，数据库脚本要手动导入到MySQL中。启动顺序上，我一般先启动Redis，再启动MySQL，然后启动后端，最后启动前端。很多同学反过来，前端启动得飞快，后端报错一堆，就开始怀疑代码有问题，其实Redis连不上才是真凶。

一个容易让人崩溃的配置点是MySQL的时区设置。连接串里一定要显式写serverTimezone=Asia/Shanghai，否则Java 8以上版本可能因为时区差异报错，或者数据库里存的时间比实际时间差8个小时。这个问题几乎每年都有人问，所以我在application.yml里的写法一般是：

spring: datasource: url: jdbc:mysql://localhost:3306/game_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver

4.2 前后端联调和远程调试：别让跨域卡掉一半时间

前后端分离开发时，最烦的就是跨域。前端本地跑在localhost:5173，后端跑在localhost:8080，直接用axios请求后端必然触发CORS报错。我推荐的做法不是在后端加一堆@CrossOrigin注解，而是利用前端Vite的代理功能，让浏览器以为所有请求都来自同一个地址：

// vite.config.js server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, // 如果后端接口没有统一 /api 前缀，这里可以重写 // rewrite: (path) => path.replace(/^\/api/, '') } } }

前端请求里全部以/api开头，Vite在开发阶段内部转发到8080，这样就不存在跨域了。生产环境部署时，Nginx再做同样的反向代理，前后端照样是同源。这套方案能让接口联调顺畅很多。

再来说说“远程调试”。有些同学手里拿到的源码是别人电脑上开发出来的，自己在本地跑就是出问题，或者遇到只在Linux服务器上出现的bug，本地复现不了。远程调试的本质是让本地的IDE连接远程JVM，实时看变量值、打断点、单步跟踪。Java虚拟机本来就支持这个机制，配置方法也不复杂。

在服务器启动后端时加上一串JVM参数：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar game-store.jar

然后在IDEA里选择Run -> Edit Configurations -> Remote JVM Debug，填上服务器IP和端口5005，并选择跟你源码匹配的Module，就能打断点了。需要注意：远程调试会让目标进程暂停在某一行，生产环境千万不要开启；而且5005端口不要暴露到公网，否则容易被人扫描利用。我通常只在对服务器部署环境不放心时才临时开一次，排查完马上关掉，这个习惯希望大家养成。

4.3 服务器部署与运维：从jar包到Nginx一站式搞定

部署是很多同学最慌的环节，其实只要按部就班做，成功率很高。前端打包命令是npm run build，产物是一个dist目录；后端打包命令是mvn clean package -DskipTests，产物是一个可执行的jar包。先把这两个东西准备好，后面就是“照本宣科”。

服务器上比较省心的做法是装一个宝塔面板，但不建议依赖它的“一键部署”去掩盖你的理解。我更推荐手动走一遍核心步骤，至少要知道后面发生了什么：

# 1. 上传 jar 包 scp target/game-store.jar user@server:/opt/app/ # 2. 启动后端（这里用 systemd 更专业） cat > /etc/systemd/system/gamestore.service << EOF [Unit] Description=Game Store Service After=network.target [Service] User=root WorkingDirectory=/opt/app ExecStart=/usr/bin/java -jar /opt/app/game-store.jar Restart=always [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable gamestore systemctl start gamestore

前端dist目录放到Nginx的静态站点目录，Nginx配置里写两个关键块：一个用来处理前端路由history模式（保证页面刷新不404），另一个把/api请求反向代理给后端jar：

server { listen 80; server_name your-domain.com; root /opt/www/dist; index index.html; location / { 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

部署完成后记得改数据库密码、关闭Redis的protected-mode、删掉不用的演示账号。如果演示需要支付宝沙箱回调，服务器必须能被公网访问到回调接口，沙箱支付才能真正流程闭环。有些同学本地跑的时候用内网穿透工具把8080映射到公网，也能实现回调，但正式答辩的前一天晚上，我强烈建议直接在服务器上完整跑一遍演示流程，避免临时网络故障。

5. 高频问题排查与答辩准备

5.1 这些问题，几乎每台机器都会遇到

我把带项目时高频遇到的现象和排查思路整理成一张表，大家对照着自己先检查一遍，能省下大量找人帮忙的时间。

5.2 一份能顺利过关的毕设文档和答辩演示怎么准备

技术代码写得再漂亮，文档和演示拉胯一样会丢分。文档部分至少要包含：项目背景与意义、需求分析、功能模块、数据库设计、接口设计、系统测试、部署说明、总结展望。这里不建议直接堆网上免费模板，而是把你自己跑的每步截图放上去，哪怕页面再朴素，真实感都能加分。

答辩老师看到你是“游戏售卖商城”这个题目，通常会围绕四个问题展开：

• 为什么用JWT而不是Session？答：前后端分离架构下，客户端无法依赖Cookie传递Session，JWT无状态、可横向扩展、前端存储与传递简单。
• 超卖问题怎么解决的？答：数据库原子扣减是兜底，Redis预扣减可以提升并发上限，唯一索引防止重复发卡。
• 支付回调为什么能保证不重复发货？答：支付流水表唯一索引 + 事务状态判断，重复回调直接返回成功，不重复处理业务。
• 为什么不用微服务？答：项目属于单体应用，业务量级和团队规模都不需要微服务，单体架构部署简单、排查方便，如果未来订单量增长可以按模块拆分。

演示前一定提前准备一个干净的测试账号、一个上架状态的商品、一批未售卡密。现场最怕的就是注册时验证码收不到、支付时沙箱账号密码输错。这些本来只需2分钟就能准备好的事，却常因为紧张被无限放大。

写在最后

最后说点实在的。我见过太多拿到源码的同学，第一反应是双击运行，跑不起来就反复找环境问题，最后才发现是SQL没导入，或者是Redis没启动。远程调试不是万能药，它能帮你把“生产环境才出现”的问题看清楚，但真正决定你答辩能不能过的，是你有没有把核心业务逻辑亲手串一遍。带项目这些年，我的体会是：游戏售卖商城这个题目，技术栈不新也不炫，但胜在业务闭环完整，只要肯花一个周末把订单、支付、库存这三条线理清楚，它就是你简历上拿得出手的项目，也是答辩场上最有底气的谈资。如果你正在被某个环境问题卡住，别急着删代码，先把日志打开看第一行报错，多半是时区、字符集或Redis没启动。祝你能在这个项目里找到真正属于自己的收获。