企业官网建设流程全解析

1. 项目概述与核心需求解析

1.1 一句话看懂这个项目

这个毕业设计项目，简单来说就是做一个基于Java Web的虚拟游戏道具交易平台。玩家在这个平台上可以把自己打游戏打出来的装备、道具、皮肤、账号资源挂上去卖，也可以去搜别人挂出来的好东西买下来。整体架构采用B/S模式（Browser/Server，浏览器/服务器模式），用户不需要安装任何客户端，打开浏览器就能访问使用。

项目名称里反复出现了几个关键词：java、Web、B/S架构、游戏道具、装备流通。这其实已经把技术路线和业务方向都定死了一个Java系的Web应用，面向游戏虚拟商品交易场景。对于计算机专业的学生来说，这是一个非常经典的"电商系统"变种题目，既有通用电商的共性逻辑（商品、购物车、订单、支付、用户），又有游戏领域特有的业务细节（装备属性、道具分类、品类差异、交易安全）。

1.2 它解决了什么真实问题

先别急着写代码，得想清楚这个平台到底解决什么问题。游戏玩家在游戏里打出来的好装备，自己用不上、或者想换点零花钱，以前只能私下交易——论坛发帖、游戏频道喊话、QQ群对接。这个模式的问题太多了：没有担保机制容易被骗、没有统一的商品标准信息零散、价格不透明、交易记录无法追溯。

所以这个平台的核心价值就四个字：流通+信任。给虚拟道具一个集中的展示和交易场所，用平台化的方式把商品信息结构化、交易流程标准化、买卖双方信用化。毕业设计如果能在论文里把这一点剖析清楚，答辩的时候就很加分。

1.3 适合谁参考

• 计算机科学与技术、软件工程专业的本科生，选题阶段或开发初期想参考整体架构。
• Java Web方向的求职者，想通过一个完整的项目串一遍SSM/Spring Boot技术栈。
• 需要快速上手B/S架构电商类项目的初学者，本项目属于中等规模，比图书管理系统复杂，比真正的大型商城简单，非常适合练手。

我的建议很直接：不要把这个题目当成一个"交差"的任务，它完全有潜力写成一份有亮点、能展示的毕设项目。下面从设计思路、技术实现、实操过程到踩坑记录，完整拆给你看。

2. 整体设计与技术选型思路

2.1 为什么是Java Web + B/S架构

很多人可能觉得这个选择是"题目规定的"，没什么好分析。但答辩老师第一个问题大概率就是："你为什么用这个技术方案？"这个问题答不好，项目做得再花哨也白搭。

Java Web在高校毕业设计里几乎是"标准答案"，原因很现实。第一，Java生态的资料极其丰富，从基础的Servlet/JSP到Spring Boot微服务，遇到任何问题都能搜到解决方案，这对时间有限的学生来说是巨大的优势。第二，Java的面向对象特性和虚拟商品交易这个业务场景天然契合，商品、订单、用户、交易记录都能建模成对象，业务逻辑的表达非常自然。第三，Java在电商领域的生产级应用极为成熟，面试的时候聊这个项目，面试官不会觉得陌生。

B/S架构的选择逻辑就更简单了：无需安装客户端，所有用户通过浏览器访问。玩家卖道具，不需要下载一个什么"道具交易客户端"，打开网页就能用。系统升级也方便，只改服务器端的代码，用户浏览器刷新一下就是新版本。对比C/S架构（Client/Server）那种要逐台机器升级客户端的模式，B/S在维护成本上的优势是压倒性的。

2.2 技术栈选型：SSM还是Spring Boot？

这个决定直接影响你后面几个月的开发体验。虽然SSM（Spring + Spring MVC + MyBatis）是经典组合，课程也教得多，但我强烈建议用Spring Boot来做。

原因就一句话：Spring Boot把大量繁琐的配置自动化了。SSM时代你要手动配置web.xml、Spring容器、MyBatis映射器，每一处都可能出问题，配置一对就大半天。Spring Boot通过自动配置和starter依赖，让你把精力从"配置框架"转移到"写业务代码"上。对于毕设这种有明确时间节点的项目，节省下来的时间非常宝贵。

推荐组合是：Spring Boot 2.x/3.x + MyBatis-Plus + MySQL 8.0 + Vue 3（或Thymeleaf）+ Bootstrap。前端选Vue还是模板引擎，取决于你的时间投入。如果前后端分离，Vue独立开发调试体验更好，但需要额外学Node环境、跨域处理；如果用Thymeleaf服务端渲染，前后端不分离，一个Java后端就全搞定了，工作量小但页面交互体验弱一些。作为毕设，我的建议是后端优先把Spring Boot API做好，前端如果时间紧张用Bootstrap+Thymeleaf快速实现，如果时间充裕上Vue做一个独立前端。

2.3 数据库设计的三张核心表

虚拟商品交易平台的数据模型不像传统电商那么复杂，但有一个关键点必须处理好：商品数据的灵活性和交易数据的安全性。这两者经常是矛盾的，需要在数据库设计时做取舍。

核心表至少包括这几张：

用户表（user）字段：id（主键）、username、password（MD5加盐或BCrypt加密）、phone、email、role（角色区分：普通用户/管理员）、status（账号状态：正常/封禁/注销）、create_time、last_login_time。 角色字段相当重要，没有它，后台管理功能就无从谈起。建议用枚举值：0-普通用户，1-管理员。

商品表（goods）字段：id、seller_id（卖家外键）、goods_name（名称）、game_category（所属游戏/道具分类）、goods_type（类型：装备/消耗品/皮肤/材料等）、price（价格）、description（描述）、status（在线/下架/已卖出）、create_time、update_time、view_count（浏览数）。 这里有个设计难点：不同游戏的装备属性差异很大，例如《DNF》里的武器有强化等级、独立攻击力，《英雄联盟》的皮肤有特效、稀有度。建表时如果全做成字段，表会超级臃肿。实务做法是：公共信息放商品主表，差异化属性放一个attributes的JSON类型字段或独立的扩展表。MyBatis-Plus对JSON字段的支持也还可以，这个设计在答辩时是一个不错的加分点。

订单表（order）字段：id、order_no（订单编号，建议用时间戳+随机数生成）、goods_id、buyer_id、seller_id、amount（成交金额）、status（创建/已支付/交易完成/已取消/退款中）、remark、create_time、pay_time、finish_time。 订单表是整个系统里最需要严谨对待的表，因为涉及两个核心问题：资金安全（哪怕只是模拟的）和交易状态一致性。状态流转必须清晰：创建订单后锁定商品、支付后标记完成、异常情况取消。数据库里要保证"同一商品不会被两个人同时下单买到"，这需要事务和锁配合，具体在第三节讲。

2.4 功能模块划分

把这个平台拆成四个大模块，每个模块再往下拆，开发计划就一目了然：

• 用户模块：注册、登录（含验证码）、个人信息维护、密码修改、我的发布列表、我的购买记录。管理员还额外有用户管理、商品审核、数据统计的功能。
• 商品模块：商品发布（上架）、商品搜索（关键词/游戏分类/价格区间）、商品详情展示、商品下架/删除、商品状态管理。这是整个系统信息量最大、最体现业务差别的地方。
• 交易模块：购物车（可选）、立即购买、订单生成、在线支付（模拟/真实接入）、订单管理（买家/卖家双视角）、交易评价。
• 后台管理模块：公告管理、用户管理、商品管理（下架违规商品）、订单总览、基础数据看板（用户数、商品数、订单量、交易额）。

你可能注意到，我特意把"购物车"标注了可选。很多同学做电商类项目，一上来就加购物车，结果购物车逻辑（全选、批量结算、库存校验）消耗了大量时间，核心的交易流程反而做得很粗糙。我建议的优先级是：商品发布→搜索→详情→下单→支付→订单管理——这条主链路优先跑通，有富余时间再补购物车和评价等增强功能。答辩时老师更看重的是主流程是否完整、业务逻辑是否严谨。

3. 核心技术难点与实现要点

3.1 登录注册：安全细节不能省

登录注册是每个Web项目都有的功能，但很多人的实现就一个用户名密码匹配，太简陋了。稍微深入一点，就能做出质量感。

密码存储必须做加密处理，绝对不允许明文入库。最常用的是MD5加盐或BCrypt。MD5本身已经不再安全，加盐（随机字符串拼接后再哈希）会好很多，但BCrypt更推荐——它是自适应哈希算法，内置盐值，而且哈希速度可以调节，抗暴力破解能力更强。Spring Security里有BCryptPasswordEncoder可以直接用，几行代码就集成好了。

注册时建议做验证码校验。最简单的做法是用Java生成四位数验证码图片存到Session里，前端刷新验证码。虽然现在用Redis分布式存储更工业级，但毕设阶段Session方案够用。它能挡住刷注册接口的脚本，也能在答辩时解释"为什么这样设计"。

登录后的会话保持，用Session就够了，注意设置合理的过期时间（比如30分钟），并在用户操作时自动续期。如果要保存登录状态（记住我），那就是Cookie+Token的方案，复杂度会上升，看时间决定要不要做。

3.2 商品发布：装备多属性是真正的亮点

游戏道具和普通商品的区别就在这。一本书的属性就是书名、作者、定价；一把游戏里的武器可能有强化等级、攻击力、暴击率、附魔效果，属性维度完全动态。

我的实现建议是：商品主表存公共字段，差异属性在发布表单里按分类动态渲染。例如前端根据用户选择的"游戏分类"，动态加载不同的属性录入控件。后端接收时把这些属性包装成一个Map或JSON字符串，存入对应的扩展字段。

一个具体的例子：假设平台上出售DNF中的一把"苍穹幕落太刀"，动态属性可能是：

{ "强化等级": 12, "独立攻击力": 432, "物理暴击": 3, "需要等级": 90, "可交易": true }

详情页渲染这个JSON，按表格一行一个属性展示。搜索时如果有"按属性筛选"需求，需要把属性字段做索引或者用数据库的JSON函数（MySQL 8.0的json_extract），但这类需求属于加分项，基础搜索按名称和价格就够用。

3.3 交易核心：订单与并发控制

商品和订单的关系是整个系统的关键，必须保证两个用户不会同时买同一样东西。一种做法是商品表加一个状态字段，下单时先查状态、标记"已锁定"，但这中间有并发窗口——两个请求同时查到"有货"，都会尝试下单。解决办法就是用数据库行级锁。

以MySQL为例，在事务里查询商品时用SELECT ... FOR UPDATE把商品行锁住。比如：

BEGIN; SELECT * FROM goods WHERE id = #{goodsId} AND status = 1 FOR UPDATE; -- 如果查到且状态正常，则创建订单、修改商品状态为已锁定 UPDATE goods SET status = 2 WHERE id = #{goodsId}; COMMIT;

第一个事务拿到锁，第二个事务的FOR UPDATE会被阻塞，直到第一个事务提交或回滚，这时它重新读到的状态已经是锁定/已卖出，就不会再继续下单了。

订单状态机的设计同样需要花心思。建议这样流转：

待付款 → 已付款/已锁定 → 交易完成 ↓ ↓ 已取消 退款中 → 已退款

买家付款动作，在模拟支付里就是一笔虚拟支付接口调用；但订单状态必须严格推进，不允许从"待付款"直接跳到"交易完成"。为了避免状态紊乱，后端在做状态更新时带条件判断，例如"只有当前状态是待付款的订单才能被取消"，不要做无条件的update。

3.4 数据库并发与事务：一个实战场景

来一个更完整的场景。用户A下单购买某装备，假设已经下单但未支付，此时用户B也在看这个装备。系统应该怎么办？

正确姿势是：A下单后把商品状态从"上架中"改为"锁定中"（或"待付款"），B在商品列表里就看不到这个装备，或者点开详情页显示"已被锁定"“暂不可购买”。商品锁定状态需要有一个超时机制，比如限时15分钟内未支付自动释放，这可以用定时任务扫描加锁超过15分钟且未支付的订单，把商品重新置回上架状态。

这里有个新手常犯的错误：商品状态和订单状态是两套状态，分别存在不同表里，但必须保持联动。商品状态变化（上架→锁定→卖出/可售）由订单驱动，两边的update最好在同一个事务里，避免中间状态不一致。

另外提一句，如果平台支持充值余额或钱包功能，涉及账务的部分更要小心。余额字段的更新不能用"读余额→算新余额→写回"，而是直接用SQL原子操作：

UPDATE wallet SET balance = balance - #{amount} WHERE user_id = #{buyerId} AND balance >= #{amount};

这个语句天然解决了并发扣款时不超扣的问题，比Java代码里先查后减安全得多。

3.5 跨域问题与前后端分离的注意事项

如果你选择Vue独立前端 + Spring Boot后端，跨域（CORS）问题几乎一定会遇到。开发环境下Vue跑在localhost:5173，后端跑在localhost:8080，两个端口不同，浏览器默认会拦截后端响应。

解决办法在Spring Boot里加一个全局配置类，允许指定的跨域来源：

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

生产部署时再收敛allowedOrigins，比如只允许你的域名。把这条配置写进笔记里，因为你十有八九会在这里卡半小时。

4. 实操过程与核心环节实现记录

4.1 环境准备与项目初始化

我实操时的环境版本如下，供参考：

• JDK 1.8（稳妥，兼容性最好）或JDK 17（Spring Boot 3.x需要）
• Maven 3.8+
• MySQL 8.0
• IDEA（社区版即可，lombok插件记得装）
• Node.js 16+（如果做前后端分离）
• 前端选型：Bootstrap 5 + Thymeleaf，或 Vue 3 + Element Plus

项目初始化两步走。第一步，在Spring官方的Spring Initializr（start.spring.io，或者IDEA内置）创建一个Spring Boot项目，勾选Spring Web、MyBatis、MySQL Driver、Validation等依赖（在你还没用安全框架时可先不勾Security）。第二步，引入MyBatis-Plus：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency>

MyBatis-Plus的好处很多：内置通用的增删改查、分页插件、条件构造器，基础的CRUD完全不用手写XML，写复杂SQL时再补充。这对赶毕设非常友好。

4.2 实体类设计：以商品为例的Model层

用Lombok简化实体类代码：

@Data @TableName("goods") public class Goods { @TableId(type = IdType.AUTO) private Integer id; private Integer sellerId; private String goodsName; private String gameCategory; private String goodsType; private BigDecimal price; private String description; private String attributesJson; // 动态属性存JSON字符串 private Integer status; // 0-下架 1-上架 2-锁定 3-已卖出 private Integer viewCount; @TableField(fill = FieldFill.INSERT) private LocalDateTime createTime; @TableField(fill = FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }

注意字段命名规范，使用驼峰命名，数据库列名使用下划线命名，再打开MyBatis-Plus的驼峰映射配置（默认开启），这样对应关系就自动建立了。商品价格必须用BigDecimal而不是double或float，否则会出现类似19.999999的精度问题，这个细节讲到数据库设计时一定要提，答辩老师很吃这套。

4.3 Controller层：接口设计的三层结构

好的接口风格应该保持简洁和规范。我习惯按资源路径组织RESTful接口：

用户模块：

商品模块：

订单模块：

Controller层的核心原则是薄：只做参数接收、权限判断、调用Service、返回统一结果。业务逻辑全部下沉到Service层，避免Controller变成大杂烩。

统一返回格式建议做一个通用类：

@Data public class Result<T> { private Integer code; // 200-成功 500-失败 private String message; private T data; }

所有接口统一返回这个结构，前端处理时只需要判断code即可。这种做法也让接口的可维护性高了不止一个档次。

4.4 Service层：业务逻辑的关键写法

以创建订单的核心方法为例，我写出关键实现思路：

@Transactional(rollbackFor = Exception.class) public Order createOrder(Integer goodsId, Integer buyerId) { // 1. 校验商品存在且状态为上架中，行锁防止并发售卖 Goods goods = goodsMapper.selectByIdForUpdate(goodsId); if (goods == null || goods.getStatus() != 1) { throw new BizException("商品不存在或已下架"); } // 2. 不允许购买自己的商品 if (goods.getSellerId().equals(buyerId)) { throw new BizException("不能购买自己发布的商品"); } // 3. 创建订单，初始状态为待付款 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setGoodsId(goodsId); order.setBuyerId(buyerId); order.setSellerId(goods.getSellerId()); order.setAmount(goods.getPrice()); order.setStatus(0); // 待付款 orderMapper.insert(order); // 4. 商品状态改为锁定中 goods.setStatus(2); goodsMapper.updateById(goods); return order; }

这里有两个核心点：@Transactional标注保证方法内所有数据库操作同一事务；selectByIdForUpdate这条自定义SQL通过FOR UPDATE拿到行锁。这两者配合，高并发下也不会出现"超卖"。

支付操作的逻辑再强调一遍，扣款用原子SQL更新余额字段，避免并发超扣。

4.5 前端页面实现：可用是第一要务

如果走前后端分离Vue路线，页面不必做得太惊艳，干净能用就行。核心页面列表如下：

• 首页：商品推荐列表、搜索框、分类导航。
• 商品列表页：支持按名称模糊搜索、按游戏分类筛选、按价格区间筛选、分页展示。这是整个系统交互最多的页面，建议做好Loading和空状态。
• 商品详情页：商品图片区（没有真图可放占位图）、属性列表渲染、价格、卖家信息、"立即购买"按钮。登录状态下展示"立即购买"，未登录则提示去登录。
• 发布商品页：动态表单，选择游戏分类后加载对应属性输入区。
• 买家订单中心：显示我买过的订单，待付款的可以取消/去支付，完成的可以评价。
• 卖家订单中心：显示我卖出的订单，支持确认发货/标记完成。
• 后台管理页：用户管理表格、商品管理表格、订单管理表格、基础统计卡片。用现成的Admin模板（如AdminLTE、vue-element-admin）能省大量UI时间。

如果选Thymeleaf服务端渲染，页面用Bootstrap 5快速布局，每次请求返回完整HTML。这种方式调试门槛低，适合不熟悉前端工程化的同学。

4.6 模拟支付功能的实现技巧

真实对接支付宝/微信支付需要商户资质，毕设阶段做个模拟支付即可，重点是订单状态的正确流转。我建议页面里做一个"模拟支付"按钮，调后端支付接口时直接生成一条支付流水记录，把订单状态从待付款置为已付款，同时给卖家加虚拟收益。数据上可以简化为：订单状态=已付款，支付流水表插入一条记录（方式标记为模拟支付）。

这样设计的好处是：系统里保留了支付流水的概念和表结构，将来接入真实支付时只需要替换"模拟支付"为真实的SDK调用，业务逻辑不必大幅改动。答辩时你可以说"模拟支付是为了避免真实交易的合规和风险问题，但支付接口已抽象，真实接入是可行的"，这一段话在论文和答辩中都会显得专业。

4.7 部署上线：直接从IDEA到云服务器

项目完成部署上线是硬加分项。部署路径不复杂，把Spring Boot项目打成可执行Jar包放上云服务器（Linux），装好JDK和MySQL，执行：

java -jar game-trade-platform.jar --spring.profiles.active=prod

生产配置用独立的application-prod.yml文件，动态参数从命令行或环境变量读取。数据库服务器的校验规则需要设置utf8mb4，不然存emoji昵称时会报错。如果手头没有云服务器，直接用本机部署演示也是可以的——关键是录制好演示视频，保证答辩时不出岔子。

前端如果是Vue，则先构建静态资源：

npm run build

dist目录里的静态文件用Nginx托管，同时配置Nginx把/api/路径反向代理到Spring Boot的8080端口。Nginx反向代理配置里有一个常见大坑：不配置proxy_set_header X-Forwarded-For等请求头，会导致后端拿不到用户的真实IP，影响某些业务判断。一个小配置，经验值却能提升不少。

5. 常见问题与排查技巧实录

5.1 数据库乱码问题

现象：注册中文用户名，列表里显示"????????"，要么就是空。

排查步骤：先看数据库表字符集是不是utf8mb4；再看连接串有没有带characterEncoding=utf8；最后看前端表单提交时charset设置。MySQL 8.0默认字符集已较友好，但建表时仍建议显式指定：

CREATE TABLE `user` ( ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

连接串里加上useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai。乱码另一个隐藏源头是：Linux系统区域设置非UTF-8，这里同样值得检查。

5.2 前端的404错误或刷新后页面丢失

Vue Router默认使用history模式，路由是前端管理的，例如访问/myOrders页面时如果直接输入URL刷新，Nginx找不到该文件，就会返回404。解决方法是Nginx配置try_files：

location / { try_files $uri $uri/ /index.html; }

这一句的含义是：若请求的文件不存在就一律返回index.html，让前端路由接管。这个问题在前后端分离项目里非常典型，你迟早会遇到。

5.3 登录后每次请求都不带Session

出现"登录成功但请求业务接口又提示未登录"的情况，大概率是浏览器没有携带Cookie。这又分两种情况：一是前后端不同端口导致跨域，且CORS配置里allowCredentials(true)与allowedOriginPatterns("*")不匹配（有些浏览器会拦截）；二是生产环境反向代理时没有转Corresponding请求头。还有一种情况，前后端域名不同但未正确设置Cookie的Domain，导致Cookie写入失败或没带出来。

排查的时候，打开浏览器开发者工具，在Network面板里看登录接口响应有没有Set-Cookie，再看业务接口Request Headers里有没有带Cookie，很快就能定位到是哪层丢失了。

5.4 定时任务释放超时订单的实现

释放超时未支付订单，我的做法不依赖额外组件（例如XXL-Job或Quartz），直接在Spring Boot里写一个定时任务：

@Component public class OrderTimeoutTask { @Scheduled(cron = "0 */1 * * * *") // 每分钟执行一次 public void releaseExpiredOrders() { // 1. 查出超过15分钟未支付且状态为待付款的订单 // 2. 订单状态改为已取消 // 3. 对应商品状态改回上架中 } }

注意在启动类上记得加@EnableScheduling注解。定时任务本身足够完成毕设需求，但如果你有时间，把任务设计为由消息队列触发（延时消息）会让架构更"工业级"，论文里可以展望。

5.5 常见问题速查表

5.6 我踩过的一个坑：图片上传后的静态资源路径

毕设商品图片上传功能，我一开始把文件保存到了本地某个磁盘目录，然后页面直接访问/images/xxx.png，结果404。原因是Spring Boot默认不映射磁盘路径到URL。解决办法是在配置类里加资源映射：

registry.addResourceHandler("/uploads/**") .addResourceLocations("file:" + uploadDir);

如果是Linux服务器，uploadDir建议使用绝对路径，例如/home/ubuntu/uploads，或者挂载到云对象存储（OSS）。毕设阶段本地映射就够用，但路径别写死在Java代码里，放到yml配置中，方便部署时调整。

6. 实战复盘：做成一个拿得出手的毕设

6.1 时间规划建议

毕业设计从零到一通常8到12周，我的建议分配：

• 第1-2周：需求分析、思路整理、数据库设计。把表结构画清楚，至少用Navicat把建表语句跑通。
• 第3-4周：Spring Boot项目骨架搭建、用户模块和商品模块完成。
• 第5-6周：订单模块和交易逻辑完成，这是技术难点集中的部分，重点测试并发场景。
• 第7-8周：前端页面整合，联调通过。全面测试主流程。
• 第9-10周：撰写毕业论文、画架构图、整理源码注释。
• 第11周：录制演示视频、准备答辩PPT、模拟答辩练习。

前两三周不要急着写代码。数据库设计多花一周时间，后面写代码会顺畅非常多，改动数据库结构引发的连锁修复才是真正耗时的。

6.2 论文和答辩的加分细节

论文里的逻辑顺序要体现工程规范：可行性分析、需求分析、系统设计、数据库设计、系统实现、系统测试。图表尤其重要，架构图（浏览器→Nginx→后端→数据库）、功能模块图、E-R图、UML时序图，这几张图画好，论文的骨架就立起来了。

答辩时重点准备三块内容：为什么选这套技术栈（Java Web + B/S的适用性）、核心业务怎么保障安全（并发下单、密码加密、订单状态机）、系统特色是什么（游戏道具多属性管理、模拟支付抽象层）。能把这三点讲清楚，整个答辩基本就立于不败之地。

系统测试部分别只写"功能测试全部通过"，设计几个像样的测试用例，例如：测试同一账号在多个页面同时下单一件商品，预期只成功一个；测试未付款订单超时后自动恢复商品可售状态；测试输入非法字符时接口返回友好错误提示。这些用例证明你考虑到了真实场景中的边界问题，这是文档和代码里最容易露怯的地方。

6.3 从毕设到简历项目的扩展方向

这个项目做完，简历上可以写的方向非常多。全栈链路：Java后端 + Spring Boot + MyBatis-Plus + Vue/Thymeleaf；业务设计：交易状态机、多属性商品建模、支付抽象；工程化技能：Git版本管理、Maven多模块拆分、Linux部署、Nginx反向代理。每一项都能撑起一个面试问题。

后续如果想继续扩展，可以考虑：引入Redis做商品热门排行榜和验证码缓存；引入Spring Security或Sa-Token做更完善的认证授权；用RabbitMQ做订单超时延时消息处理；把模拟支付替换为支付宝沙箱环境对接。每一个扩展点都能对应一个简历上的亮点。

最后提醒一个容易被忽略的事：提交源码前，把注释写好，尤其是核心业务方法上的中文注释和类头部的说明。答辩老师翻代码时看到的第一个印象，往往决定了他对整体代码质量的判断。这个项目做了，就意味着你把Java Web的内容从"会框架"推进到了"做一个完整业务系统"的程度，把这段经历讲清楚、讲扎实，不管是毕业还是找工作，都是实打实能打的牌。