企业官网建设流程全解析

简介：一份面向Java后端学习与毕业设计的社区团购系统完整资料包，涵盖用户注册/登录、商品浏览、购物车、订单管理、团购详情以及管理员后台等核心模块，适合用于课程设计、毕业设计答辩或入门级电商项目实战。包体共810个文件、约15.05MB，以130个Java后端源码、48个Vue页面组件、153个JS逻辑脚本及162个SVG图标为主，同时附带SQL初始化脚本与前后端工程配置说明，便于直接导入IDE运行与二次开发。系统两种角色操作路径清晰：前台用户可完成收藏、加购、下单，后台管理员可维护商品与订单数据，目录结构按前后端分层排列，且提供bak备份与bat启动脚本辅助本地部署。目前已有84人学习下载，体积虽小但业务覆盖完整，适合希望快速理解社区团购从前端界面到后端业务实现全流程的初学者。

1. 社区团购系统的设计与实现：为什么四年Java学了那么多，最后被一个成团状态机问倒

如果你拿到的毕设题目是“基于Java的社区团购系统设计与实现”，那它和普通商城类题目有个本质区别：它不是让你把商品、购物车、订单的CRUD做完就收工，而是要处理一个带状态的交易闭环——用户下单后凑够人数才成团，没凑够要退款，团长要按成团订单拿分佣。这套逻辑里最值钱的部分不是增删改查，而是“成团”这个状态到底怎么设计、并发情况下库存为什么不超卖、分佣金额为什么不能算错。正好，这几个点也是答辩现场老师最爱追问的“八股”。

这篇文章想给你一条相对完整的落地路径：从技术选型、工程骨架、数据库设计，到成团链路的核心代码，再到开题报告和论文怎么写，最后用一个并发测试证明系统没坑。适合正在做这个题目的计算机专业学生，也适合想用完整Java全栈项目练手但还没想清楚主线的开发者。

2. Java技术栈与工程骨架：Spring Boot + MyBatis-Plus 的落地选型和环境配置

拿到这种毕业设计题目，第一反应通常是“我该用什么框架”。我的建议很简单：别为选型纠结超过半天。社区团购系统的开发量集中在业务规则上，不在基础设施上。选一套资料最多、自己能驾驭的技术栈，比选一套最新最炫但没人踩过坑的框架重要得多。

2.1 技术选型的三个硬约束：答辩能讲、开发量可控、拿得出手

常见的毕设技术方案是 Spring Boot + MyBatis-Plus + MySQL，前端可以用 Vue 3，也可以退回 Thymeleaf。这套组合的底气在于：Spring Boot 是 Java 后端的事实标准，MyBatis-Plus 把单表 CRUD 几乎消灭掉，你没必要手写一堆重复的 XML Mapper 来证明自己很努力。答辩时老师问“为什么选 MyBatis-Plus”，你可以答出“减少样板代码，把精力集中在成团状态机和库存扣减这类核心业务上”，这句话在答辩现场很加分。

有些学校的老选题系统还在和 JSP 挂钩，但我不建议新项目再用 JSP 搭页面。倒不是 JSP 不能做，而是前后端不分离的写法在论文里很难把“系统设计”和“系统实现”两章写厚。你需要的不是更复杂的框架，而是一个能让你把核心逻辑讲清楚的最小骨架。如果导师没有硬性指定，Spring Boot 2.7 + JDK 8 是最稳的组合；如果导师要求新版，再整体切到 Spring Boot 3 + JDK 17，不要混用。

2.2 Java环境配置：JDK、Maven与application.yml，一次调对不返工

环境问题听着基础，但它确实是“java启动失败怎么解决”这类搜索里出现频率最高的源头。最常见的情况是 IDEA 里 Project SDK 是 17，Maven 的 JDK 是 8，Spring Boot 版本又不匹配，启动直接抛 UnsupportedClassVersionError。统一版本这件事没捷径：确认 IDEA 的 Project Structure 里 SDK 和 Language Level 一致，确认 Maven 的 JDK for Importer 也指向同一个版本，再在 pom.xml 里固定 spring-boot-starter-parent 版本。

下面是一份可以直接抄的 application.yml 配置，我一般会把这些参数写全：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/community_group?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这段配置里有三个参数值得多说两句。第一个是 url 里的 serverTimezone=Asia/Shanghai，MySQL 8 的驱动默认对时区很敏感，不写它启动时会直接报时区错误，而且就算启动成功，订单创建时间也可能比本地时间差 8 小时，很影响后面的分佣结算对账。第二个是 map-underscore-to-camel-case，它负责把数据库的 user_name 自动映射到实体类的 userName，这个开关不开，你写出来的实体查询结果会全是 null，而 MyBatis-Plus 的 BaseMapper 又不会给你任何报错提示，排查起来很痛苦。第三个是 logic-delete-field，给所有表统一加一个 deleted 字段做逻辑删除，比物理删除安全，写论文时也能作为“系统设计考虑了数据安全”的一个细节。

2.3 工程目录划分：用一个最小可运行的项目撑起整篇论文

工程结构不需要花哨，但要有层次。我的习惯是把 controller、service、mapper、entity、config、common 六层分清楚，其中 common 放统一的返回结果 Result 和异常类。不要为了省事把业务代码全塞在 controller 里，那样论文的“系统实现”一章会很难写，因为你在代码里根本分不出模块边界。

一个最小可运行的目录结构类似这样：

community-group-buy/ ├── pom.xml └── src/main/java/com/example/community/ ├── CommunityApplication.java ├── common/ │ ├── Result.java │ └── BusinessException.java ├── config/ │ └── MybatisPlusConfig.java ├── controller/ │ └── UserController.java ├── entity/ │ └── User.java ├── mapper/ │ └── UserMapper.java └── service/ ├── UserService.java └── impl/ └── UserServiceImpl.java

实体类是所有后续工作的起点，它的写法直接影响 MyBatis-Plus 的行为。以一个用户实体为例：

@Data @TableName("user") public class User { @TableId(type = IdType.AUTO) private Long id; @TableField("user_name") private String userName; /** 0-普通用户 1-团长 2-管理员 */ private Integer userType; private String phone; private String password; @TableLogic private Integer deleted; }

@TableName 指定物理表名，@TableField("user_name") 显式声明列映射，这样即使全局驼峰映射被关掉，这一列也能正确对应。userType 用 Integer 而不是布尔值，是为了后续扩展角色不用改表结构。@TableLogic 配合刚才 yml 里的逻辑删除配置，调用 deleteById 时 MyBatis-Plus 会自动把 deleted 置 1，而不是真正删数据。这三个注解是 MyBatis-Plus 的常规用法，但很多新手只写 @TableName 不写 @TableField，导致列名对不上时一脸懵。

对应的 Mapper 也简单：

@Mapper public interface UserMapper extends BaseMapper<User> { }

继承 BaseMapper 后，单表的 insert、selectById、updateById 都直接可用，不需要任何 XML。这部分是 MyBatis-Plus 最省力的地方。真正需要手写 SQL 的，是后面要说的库存扣减和成团计数，那才是社区团购系统的业务核心。

3. 数据库设计与建表SQL：从实体类生成DDL，订单与商品表怎么定才是对的

数据库设计决定了论文里最能体现“设计能力”的一章，也决定了代码写起来是顺畅还是别扭。社区团购系统的主线不复杂，但它不是一张订单表就能解决的。订单主表和订单明细表必须拆开，成团信息要单独一张表，团长分佣需要一张结算表落账。下面按实际开发顺序讲清楚。

3.1 最少能跑通业务的五张核心表：用户、商品、订单、订单明细、成团记录

社区团购的表设计有一个和普通电商不同的关键点：订单不只属于用户，还属于某个团。所以订单表里除了 user_id，还要有 group_id 和 leader_id，分别表示用户参加了哪个团、这个团由哪个团长发起。这是社区团购区别于普通商城最明显的表结构差异。

订单主从表的设计不是小题大做。如果一个订单只买一件商品，确实可以把商品名、价格直接塞进 orders 表，但社区团购的团购活动往往允许用户一次下单多件同一商品，后续团长的分佣也要按订单明细去汇总。把 order_item 独立出来，好处是将来要出一个“哪个商品卖得最好”的报表时，直接对明细表分组汇总就行，不需要解析字符串。goods_name 和 price 在明细表里复制一份，这是刻意冗余，目的就是不让历史订单显示的商品名和价格随商品表变动。论文里如果被问到范式问题，可以解释为“在第三范式与查询性能之间做了权衡”。

3.2 用实体类生成建表SQL：一个反射小工具解决实体和表不同步

你有没有过这种经历：实体类加了字段，数据库表忘了加列，启动后 SQL 一执行就报 Unknown column；或者反过来，表结构改好了，实体类没同步，查出来全是 null。这种实体和 DDL 不同步的问题，在毕设开发阶段几乎每天都能遇到。网上经常搜“mybatisplus根据java实体类生成创建表的sql语句”，其实 MyBatis-Plus 本身不带正向建表功能，但我们可以自己写一个几十行的反射工具，让实体类成为唯一的事实来源。

思路是：扫描实体类的字段，读取 MyBatis-Plus 的表名和字段注解，把 Java 类型映射成 MySQL 类型，拼接成 CREATE TABLE 语句，在应用启动时自动执行。核心代码可以写成这样：

public class DdlGenerator { public static String generate(Class<?> clazz) { TableName tableName = clazz.getAnnotation(TableName.class); String table = tableName == null ? clazz.getSimpleName().toLowerCase() : tableName.value(); StringBuilder sb = new StringBuilder(); sb.append("CREATE TABLE IF NOT EXISTS `").append(table).append("` (\n"); Field[] fields = clazz.getDeclaredFields(); for (Field field : fields) { TableField tf = field.getAnnotation(TableField.class); // @TableField(exist = false) 表示该字段不对应数据库列 if (tf != null && !tf.exist()) { continue; } String column = field.getName(); if (tf != null && !tf.value().isEmpty()) { column = tf.value(); } sb.append("`").append(column).append("` ").append(mapType(field.getType())); if (field.isAnnotationPresent(TableId.class)) { sb.append(" PRIMARY KEY AUTO_INCREMENT"); } sb.append(",\n"); } sb.append(") ENGINE=InnoDB DEFAULT CHARSET=utf8mb4"); return sb.toString(); } private static String mapType(Class<?> type) { if (type == String.class) return "VARCHAR(255)"; if (type == Integer.class || type == int.class) return "INT"; if (type == Long.class || type == long.class) return "BIGINT"; if (type == BigDecimal.class) return "DECIMAL(10,2)"; if (type == LocalDateTime.class) return "DATETIME"; return "VARCHAR(255)"; } }

这个工具有几个明显的边界：反射拿不到字段的注释，所以数据库列的 COMMENT 需要手动补；它也无法生成唯一索引和联合索引，订单号的唯一约束还是得手工写。所以我不建议把这个工具当成万能方案，它的真正价值是保证“表结构跟随实体走”，避免你改了实体忘了改表。实际项目里我一般只在启动时执行一次，表建好后自动跳过，不影响快速迭代。答辩时如果老师问起，也可以说这是“实体与表结构一致性保障机制”，比单纯说“我手写SQL”听起来更完整。

3.3 索引设计与唯一约束：订单号必须有唯一索引，这不是小题大做

很多毕设项目只有几百条测试数据，索引的作用根本体现不出来，但数据库设计的规范性还是要从索引上体现。至少三处索引不能省：orders 表的 user_id 和 group_id，goods 表的 category_id，以及 orders 表的 order_no 唯一索引。

-- 订单号唯一，防止重复创建订单 ALTER TABLE orders ADD UNIQUE INDEX uk_order_no (order_no); -- 我的订单列表页：按用户查 CREATE INDEX idx_order_user ON orders (user_id); -- 查看某团所有订单：按团查 CREATE INDEX idx_order_group ON orders (group_id); -- 商品分类筛选 CREATE INDEX idx_goods_category ON goods (category_id);

order_no 的唯一索引尤其重要。生成订单号时如果并发撞了，数据库会直接拒绝插入，应用层再捕获异常重试，这是一种兜底机制。订单号我习惯用“年月日 + 时间戳 + 随机数”，长度控制在 30 位以内，避免索引过大。user_id 和 group_id 上的普通索引，对应的是“我的订单”和“团购详情”两个高频查询，就算现在数据量小，索引的命中在 explain 里也能看得出来。

写论文的数据库设计章节时，把这三条索引 SQL 放进表格，配上一句“通过索引设计保证订单查询和唯一性约束在数据量增长时仍然有效”，这一小节的内容就充实了。注意别走入另一个极端：给所有字段都加索引。写操作变慢不说，答辩时老师可能反问你“这个索引的使用场景是什么”，答不上来反而露怯。

4. 下单、成团与分佣的核心链路：事务和并发控制写在哪一步，答辩才问不倒

社区团购和普通电商系统最大的区别不在页面，而在订单状态流转。普通电商是下单后直接支付、发货、完成；社区团购多了一个“成团”的中间状态。这个状态是整篇论文的题眼，也是你在答辩时可以深度展开的地方。本意核心的一句话是：成团不是下单的附属动作，而是一条独立的业务规则。

4.1 成团状态机：订单状态字段怎么定义，待成团与已成团不能混为一谈

订单状态字段建议按 0 到 4 定义，每个数字对应一个明确的业务阶段：

这个状态机的好处在于，支付和成团被拆成了两个独立事件：支付成功只把状态从 0 改成 1，成团成功才把状态从 1 改成 2。很多新手会把“用户付款后立刻成团”写在一起，等于把成团这个核心业务规则给吞掉了——那这个系统就和普通商城没有区别了。

核心的下单方法要同时处理库存扣减、订单创建、成团计数三件事，并且这三件事必须在同一个事务里，任何一个失败都要全部回滚：

@Override @Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateParam param) { // 1. 库存扣减，stock >= #{count} 是防超卖的关键条件 int updated = goodsMapper.deductStock(param.getGoodsId(), param.getQuantity()); if (updated == 0) { throw new BusinessException("库存不足，下单失败"); } // 2. 创建订单，初始状态为已支付待成团 Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(param.getUserId()); order.setGroupId(param.getGroupId()); order.setLeaderId(param.getLeaderId()); order.setOrderStatus(1); order.setPayAmount(param.getPayAmount()); orderMapper.insert(order); // 3. 成团人数 +1，返回 0 说明该团已满或不存在 int row = groupBuyMapper.increaseCount(param.getGroupId(), param.getTargetCount()); if (row == 0) { throw new BusinessException("该团已满或不存在"); } return order.getId(); }

对应的 Mapper 里，库存扣减的 SQL 长这样：

@Mapper public interface GoodsMapper extends BaseMapper<Goods> { // stock >= #{count} 同时充当条件判断和原子扣减 @Update("UPDATE goods SET stock = stock - #{count} WHERE id = #{goodsId} AND stock >= #{count}") int deductStock(@Param("goodsId") Long goodsId, @Param("count") Integer count); }

这段代码有两个值得在答辩时展开的细节。第一，@Transactional 默认只回滚 RuntimeException 和 Error，如果自定义的 BusinessException 继承的是 Exception，事务不会回滚。所以必须写 rollbackFor = Exception.class。第二，deductStock 不是先查库存再更新，而是把“库存是否足够”的判断交给数据库：UPDATE 语句的 WHERE 条件里带上 stock >= #{count}，数据库行锁保证同一商品的库存扣减是原子操作，返回的影响行数为 0 就说明库存不够。这是解决并发超卖的正确姿势，也是最容易在答辩中成为亮点的设计。

4.2 模拟支付与成团后置逻辑：别真接第三方支付，也别把支付环节省掉

毕设阶段接微信支付或支付宝不现实，需要商户号资质、回调域名配置和证书处理，光审核流程就能拖垮你的进度。但支付环节又不能不体现。常规做法是写一个模拟支付接口，接收订单号，把状态从未支付改成已支付待成团。这个“模拟”要在论文里明确写出来，当作系统预留了第三方支付接口，实际操作是模拟回调，不要试图在论文里回避它。

支付成功以后，要触发一次成团判断。判断逻辑是：查出该团当前的 cur_count，如果加一后等于 target_count，那就把该团所有状态为待成团的订单改成已成团待自提。这里要注意，不是每个下单请求都自己去做成团判断，而是把判断收敛到一个方法里，避免多个线程同时更新成团状态时出现“团满了但订单状态没变”的问题。失败场景也要处理：超过活动截止时间还没凑满的团，要有定时任务扫描并把相关订单改为已取消、触发模拟退款。这个定时任务用 Spring 自带的 @Scheduled 就能写，不用引 Quartz。

系统里还要有“超时未支付自动取消”的任务。如果不写，你测试时会攒下一堆脏订单，后续报表和分佣数据全对不上。定时任务的实现不复杂，但它是“系统设计完整性”的体现，论文的“系统实现”章可以单独用一个小节写它。

4.3 团长分佣计算：金额精度和结算状态，一个都不能含糊

社区团购里的团长，本质是一个推广获客的角色。团长开团后，该团下所有成团订单都要按比例给团长分佣。分佣计算有两个前提：一是在订单已成团后触发，未成团退款的订单不能进入分佣；二是金额计算必须用 BigDecimal，不能用 double。

分佣逻辑单独抽一个 CommissionService：

@Service public class CommissionServiceImpl implements CommissionService { /** 佣金比例从配置表读取，方便运营调整，也方便论文里写成“可配置项” */ @Value("${commission.rate:0.10}") private BigDecimal rate; @Override @Transactional(rollbackFor = Exception.class) public void settleCommission(Long orderId) { Order order = orderMapper.selectById(orderId); if (order == null || order.getOrderStatus() != 2) { // 只有已成团订单才允许结算佣金 throw new BusinessException("订单状态不允许结算佣金"); } BigDecimal commission = order.getPayAmount() .multiply(rate) .setScale(2, RoundingMode.HALF_UP); CommissionRecord record = new CommissionRecord(); record.setOrderId(orderId); record.setLeaderId(order.getLeaderId()); record.setAmount(commission); record.setStatus(0); // 0-待结算 1-已结算 commissionRecordMapper.insert(record); } }

这里有一个 Java 的经典精度坑：BigDecimal 的构造器如果传的是 double，例如 new BigDecimal(0.1)，得到的不是一个精确的 0.1；正确做法是传字符串或者用 BigDecimal.valueOf()。乘法结果再用 setScale(2, RoundingMode.HALF_UP) 保留两位小数，否则分佣金额可能出现一串诡异的尾数，把“0.30000000000000004”这种浮点数问题直接带进数据库。分佣记录里的 status 字段必须保留，它把“该算的账”和“该发的钱”分开，论文里可以说这是“财务结算流程的待结算与已结算状态设计”。

5. 避坑清单：从Java启动OOM到金额精度，五个必踩的坑与排查思路

毕设开发周期通常只有两三个月，很多时间都花在排错上。下面五条是我做类似项目时真实的踩坑记录，每一条都按“现象、原因、解决”给你理一遍。看完不能说你就不会踩了，但至少踩到的时候能快速定位，别在一个错误上耗掉两三天。

5.1 IDEA 编译报 OOM：Java heap space，调了堆大小还是报错

现象：IDEA 里点击启动 Spring Boot，编译阶段直接抛 java.lang.OutOfMemoryError: Java heap space，或者在 mvn clean package 时 Maven 构建死在“Compiling 100 source files”这一步。

原因：IDEA 的构建进程默认堆内存很小，对于包含几十个依赖的 Spring Boot 项目，编译吞吐不足就会触发 OOM。还有一部分情况是电脑里存在多个 JDK，IDEA 编译器和 Maven 用了不同版本的 JDK，导致编译行为不一致，间接放大了内存消耗。

解决：打开 IDEA 的 Help 菜单里的 Edit Custom VM Options，把 -Xmx 调到 2048m 或更高；再打开 Build Tools 的 Maven 配置，把 Importer 的 VM options 也加上 -Xmx2048m。如果项目本身引了太多无用依赖，顺手在 pom.xml 里清一遍，也经常有奇效。

5.2 MySQL 连接时报时区错误：The server time zone value is unrecognized

现象：项目启动时数据库连接池初始化失败，控制台报 The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，后面跟着一串乱码。

原因：MySQL 8 的驱动 com.mysql.cj.jdbc.Driver 默认要求连接串里显式指定时区，否则会尝试读取系统时区，一旦系统时区不是标准 UTC 格式就直接报错。

解决：在 jdbc url 末尾加上 serverTimezone=Asia/Shanghai 和 useSSL=false。注意 useSSL 不是必须，但如果你的 MySQL 没配 SSL 证书，加上它能少一些连接阶段的握手警告。如果已经启动了，还要确认 MySQL 服务端时区设置，命令行里执行 show variables like '%time_zone%'，把它和连接串统一起来。

5.3 MyBatis-Plus 查出来的字段全是 null：日志里明明是空的

现象：调用 selectList 查用户表，数据库里 user_type 字段有值，但实体对象的 userType 是 null。其他字段可能正常，可能也异常，表现不固定。

原因：数据库列名是 user_type，实体属性是 userType，MyBatis-Plus 的默认驼峰映射没生效，或者写 SQL 的时候别名和实体属性对不上。更隐蔽的一种情况是实体里用了 Lombok 的 @Data，但字段名是 uType 这种不符合驼峰规则的写法，映射直接错位。

解决：先在 application.yml 确认 map-underscore-to-camel-case: true 没被注释掉，然后在实体字段上加 @TableField("user_type") 双保险。排查顺序是：先看 SQL 日志确认查询的列名，再看实体注解，这两个地方至少有一处能说明问题。

5.4 并发下单库存变负数：压测一跑，超卖出现了

现象：用 JMeter 或自己写多线程脚本模拟 20 个用户同时抢同一商品，跑完后 goods 表的 stock 字段变成负数，订单却成功创建了。

原因：代码写成先 SELECT stock 判断库存是否充足，再 UPDATE stock 减一。两个操作之间有时间窗口，多个线程读到同一个库存值，各自认为“库存够”，然后一起执行扣减，库存直接被扣穿。

解决：把扣减和判断合并成一条 UPDATE 语句，例如 UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock >= 1，检查受影响行数为 0 就说明库存不足。这是并发扣库存的标准解法，它把原子性问题交给了数据库的行锁。相关代码在第四章的 deductStock 里已经写过，这里不再重复。

5.5 分佣金额出现 0.30000000000000004：Java数据类型选错了

现象：佣金率 0.03，订单实付金额 10 元，算出来的佣金不是 0.30，而是一长串小数 0.30000000000000004，数据库里存不下，页面显示也诡异。

原因：double 和 float 是二进制浮点数，二进制无法精确表示 0.1、0.03 这类十进制小数。用 double 做金额乘法，误差就会在计算过程中累积。

解决：业务里所有金额一律用 BigDecimal，数据库字段用 DECIMAL(10,2)，并且创建 BigDecimal 时优先用字符串构造器，例如 new BigDecimal("0.03")、BigDecimal.valueOf(0.03)。不要直接 new BigDecimal(0.03)，那个构造器反而会用二进制浮点数初始化，得不到精确值。这个坑不只存在于分佣场景，订单金额、退款金额、补贴金额全都要按这个规则处理。

6. 答辩前的最后一步：用并发下单测试证明系统没有超卖

系统写到能跑通页面只是第一步，答辩时不光要演示功能，还要拿出验证手段证明核心逻辑是可靠的。针对社区团购最容易被追问的并发超卖问题，最好的办法是写一个集成测试，模拟多个用户同时抢购同一商品，跑完后校验库存余量和成功下单数是否对得上。

我一般会用 Spring Boot Test 加 JUnit 写一段类似这样的代码：

@SpringBootTest class ConcurrencyOrderTest { @Autowired private GoodsMapper goodsMapper; @Autowired private GroupBuyService groupBuyService; @Test void concurrentOrderShouldNotOversell() throws InterruptedException { Long goodsId = 1L; int threadCount = 20; int stockBefore = goodsMapper.selectById(goodsId).getStock(); ExecutorService pool = Executors.newFixedThreadPool(threadCount); CountDownLatch ready = new CountDownLatch(threadCount); CountDownLatch start = new CountDownLatch(1); CountDownLatch done = new CountDownLatch(threadCount); AtomicInteger successCount = new AtomicInteger(); for (int i = 0; i < threadCount; i++) { pool.submit(() -> { ready.countDown(); start.await(); try { groupBuyService.createOrder(buildParam(goodsId, 1)); successCount.incrementAndGet(); } catch (BusinessException ignored) { } done.countDown(); }); } ready.await(); start.countDown(); done.await(); pool.shutdown(); int stockAfter = goodsMapper.selectById(goodsId).getStock(); assertEquals(stockBefore - successCount.get(), stockAfter); } }

这段测试的核心逻辑是：让 20 个线程在 CountDownLatch 的控制下尽可能同时调用 createOrder，成功数由 successCount 记录，结束后校验“初始库存减成功下单数等于剩余库存”。如果库存扣减逻辑不是原子的，stockAfter 会小于预期值，测试直接失败。这个测试跑通后，记得把结果截图放进论文的系统测试章，比单纯写“经测试系统运行正常”有说服力得多。答辩现场如果老师追问“你怎么验证并发正确性”，直接打开这段测试跑一遍就是最好的回答。

这类测试跑之前有一个重要前提：测试数据要干净。我习惯在测试方法里先清理指定商品的脏订单，再重置库存，避免上一次运行的失败数据干扰本次结果。为了省事，也可以在 application-test.yml 里单独配置一个测试库，和开发库分开，这样不管怎么造数据都不影响正常开发。备份方面，开发过程中我会定期用 mysqldump 导出一份 SQL 放项目根目录的 docs 文件夹，改错表结构时随时可以原地恢复，也算给自己留了后悔药。

这个项目做完后我最深的体会是：它的难点从来不在于“用 Java 写一个系统”，而在于把成团这条业务链路拆开、想清楚、用对每一步的并发控制。当你把并发测试跑绿的那一刻，心里会对整个系统踏实很多，这种底气在答辩现场比背任何八股都有用。希望帮到你。

本文还有配套的精品资源，点击获取