Java Spring Boot提交订单功能开发：一致性设计、事务与防超卖实战

做苍穹外卖做到 day08，任务终于从"看菜""加购物车"走到了"提交订单"。我最初觉得这块挺简单的：把购物车的数据搬到订单表，删掉购物车，完事。可真动手写才发现，一个 submit 接口背后牵扯到地址校验、菜品状态、金额计算、订单明细快照、库存扣减和事务回滚一整套链路，任何一个环节想当然，联调时都会被前端和测试一起找上门。这篇文章把我实现"提交订单"的完整思路、关键代码和踩坑过程整理出来，给正好学到这里的人，也给所有用 Java + Spring Boot + MyBatis 写订单模块的人当个参考。

1. 提交订单：整个外卖链路里最考验"一致性"的一环

1.1 一次点击背后，后端究竟要处理多少步

用户在前端点"提交订单"，按钮一触发，请求打到/user/order/submit，后端要处理的事情远不止"插入一条订单记录"。我当时按业务顺序拆了一遍，至少有这么几件事：

• 校验地址簿：地址必须存在、必须属于当前登录用户、字段不能缺。
• 查询购物车：当前用户购物车里的所有条目，购物车为空直接拒绝。
• 校验菜品状态：菜品是否还在售、是否下架、库存是否够。
• 计算订单金额：逐项累加菜品单价乘数量，后端重新算，不能信前端传的总额。
• 生成订单主表记录：状态、支付状态、订单号、收货人快照、金额快照。
• 生成订单明细记录：每个菜品一条，包含名称、图片、价格、数量。
• 清空购物车：下单成功后购物车要清掉，不能留着再下一单。

这一串操作里，"地址存在""购物车非空""菜品在售""金额算对""订单落库""明细落库""购物车清空"必须全部成功，只要中间任何一个步骤失败，前面已经写入的数据就必须全部回滚。

我拿这个去跟新同事讲的时候，用了句大白话：提交订单不是一个"插入动作"，而是一个"对账动作"。你要同时保证业务数据正确、存储数据完整、用户界面状态干净，三件事缺一不可。

1.2 三个最常见的"想当然"

学习项目做到这个阶段，很多人的代码其实是这么写的：

• 金额直接让前端传一个 totalAmount，后端存进去就算完。
• 库存先select stock from dish where id = ?，判断 stock 大于等于购买数量再执行update dish set stock = stock - ?。
• 下单成功把购物车一删，觉得万事大吉。

这三个"想当然"造成的后果分别是：订单金额可以被恶意请求伪造；并发下单时库存判断和扣减之间有缝隙，菜品会超卖；订单明细如果只依赖购物车里的瞬时数据而不做快照，之后菜品改名、改价、下架，历史订单显示就会跟着变。

为什么放在第一节先说这些？因为提交订单这个功能，真正难的不是写接口，而是想清楚"数据在哪个时间点以什么形态被锁定"。后面的所有代码，都是围绕这个核心问题展开的。

2. 下单前要搭好的底子：购物车与地址簿的快照设计

2.1 购物车这张表，为什么必须存名字、图片、价格

购物车表我们通常叫shopping_cart，学习项目里典型字段是这样的：

CREATE TABLE shopping_cart ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL COMMENT '用户id', dish_id BIGINT NULL COMMENT '菜品id', setmeal_id BIGINT NULL COMMENT '套餐id', name VARCHAR(32) NOT NULL COMMENT '商品名称', image VARCHAR(255) NULL COMMENT '商品图片', amount DECIMAL(10,2) NOT NULL COMMENT '单价', number INT NOT NULL DEFAULT 1 COMMENT '数量', create_time DATETIME NULL );

很多第一次写的人不理解：菜品表里已经有 name、image、price 了，购物车表为什么还要冗余一遍？直接存 dish_id，下单的时候再去关联菜品表查名称查价格不就行了？

能查，但不能只靠查。原因在于"快照"两个字。下单动作发生在某个具体时间点，这个时间点之后菜品可能涨价、可能改名、可能下架，这些都不应该影响已经生成的订单。购物车在用户加购的那一刻把菜品信息复制一层，本质上是把"用户看到的、确认要买的东西"固定下来，等真正下单时，就按这一份固定数据生成订单明细。

另外一个实际好处是减少下单时的查询压力：提交订单时只用读购物车表，不用再逐条 join 菜品表。

2.2 地址簿：下单那一刻记下的才是"当时的地址"

地址簿表address_book是我们做订单前要一起梳理清楚的另一张底表：

CREATE TABLE address_book ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, consignee VARCHAR(32) NOT NULL COMMENT '收货人', phone VARCHAR(20) NOT NULL COMMENT '手机号', province VARCHAR(32) NULL COMMENT '省份', city VARCHAR(32) NULL, district VARCHAR(32) NULL, detail VARCHAR(128) NULL, label VARCHAR(16) NULL COMMENT '标签：家/公司', is_default TINYINT DEFAULT 0 COMMENT '默认地址' );

用户提交订单时前端传过来的是 addressBookId，后端要做两件事：一是校验这个地址存在且属于当前用户；二是把地址信息完整拷贝进订单表，而不是只存一个 address_book_id。

为什么不能只存 id？很简单。订单是"历史事实"，地址簿里的地址是"可变资料"。用户今天下单用家里地址，明天他修改了地址簿里的"家"，那你一个多月后看订单记录，收货地址就不对了。做外卖项目时这问题不明显，但思路要一开始就摆正：凡是订单需要展示的信息，下单那一刻都要物化成快照，落进订单表。

这里我额外补一个细节：真正的生产中，地址簿里通常还有经纬度和楼栋门牌号，下单时还会做配送范围判断——比如某些地区不配送。苍穹外卖的课程版本不一定要求这一步，但你在设计数据结构时给orders表预留address字段做完整拼接是必须的。

2.3 从购物车到订单，哪些信息必须"物化"

我整理了一个小表，写代码前对着它逐项打钩，能少漏很多东西：

有了这张表，你再去看"提交订单"的接口，思路就清晰了：它本质上是把散落在购物车、地址簿里的可变数据，统一转换成一份不可变的历史记录。

3. 从Controller到Mapper：提交订单主流程代码怎么落地

3.1 两张核心表：orders 和 order_detail 的字段设计

下单主表 orders，我从学习项目里提炼出的通用版本：

CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, number VARCHAR(64) NOT NULL COMMENT '订单号', user_id BIGINT NOT NULL, status INT DEFAULT 1 COMMENT '1待付款 2待接单 3待送达 4已完成 5已取消', pay_status INT DEFAULT 0 COMMENT '0未支付 1已支付', order_time DATETIME NOT NULL, estimated_delivery_time DATETIME NULL COMMENT '预计送达时间', consignee VARCHAR(32) NOT NULL COMMENT '收货人', phone VARCHAR(20) NOT NULL, address VARCHAR(255) NOT NULL COMMENT '完整地址快照', amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额', remark VARCHAR(255) NULL COMMENT '备注', cancel_time DATETIME NULL, delivery_time DATETIME NULL, UNIQUE KEY uk_number (number), KEY idx_user_id (user_id) );

订单明细表 order_detail，一张独立表，和 orders 是一对多：

CREATE TABLE order_detail ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL, dish_id BIGINT NULL, setmeal_id BIGINT NULL, name VARCHAR(64) NOT NULL COMMENT '商品名称快照', image VARCHAR(255) NULL, amount DECIMAL(10,2) NOT NULL COMMENT '单价快照', number INT NOT NULL COMMENT '份数', KEY idx_order_id (order_id) );

我把订单明细独立成表，而不是在订单表里存一个 JSON 字符串，主要原因是后续接单、派单、统计销量、评价系统都要用到明细粒度数据，单独一张表查起来方便得多。日志和缓存里可以存 JSON，业务表不要这么干。

3.2 DTO与VO的边界怎么划

提交订单请求体，前端真正需要传给后端的东西其实很少：

public class OrdersSubmitDTO { @NotNull(message = "地址id不能为空") private Long addressBookId; @NotNull(message = "支付方式不能为空") private Integer payMethod; private String remark; }

购物车里的明细、金额、菜品列表，后端都有数据，不需要前端传。这里有个设计原则：前端传的字段越少，越不容易被篡改、越不容易因为字段名不一致而出错。

返回给前端的 VO 则是下单成功后需要展示给用户的信息：

public class OrdersSubmitVO { private Long id; private String orderNumber; private BigDecimal orderAmount; private LocalDateTime orderTime; }

用户支付页面和订单列表页要用到这些，所以接口返回它们就够了。不要图省事把整个 Order 实体直接返回，里面很多字段是内部状态，暴露出去没有意义，还多传不必要的流量。

3.3 订单号生成：时间戳 + 随机数看着简单，坑也不少

订单号要可读性强、有大致的时间感，所以我用的是时间戳加随机数：

public static String buildOrderNumber() { return DateTimeFormatter.ofPattern("yyyyMMddHHmmss").format(LocalDateTime.now()) + String.format("%04d", ThreadLocalRandom.current().nextInt(10000)); }

这个写法的问题是：同一秒内并发订单多了，随机数存在碰撞概率。学习项目并发量小，问题不大；但你要有这个意识。我在表结构里给 number 加了唯一索引，万一真撞了，插入时报主键冲突，事务回滚，用户重新下单就好，不会静默产生脏数据。

在生产项目里，订单号一般会改用更严格的方案：Redis 自增序列、雪花算法、美团 Leaf 这类。它们解决的不仅是唯一性，还有全局有序、跨机房不重复、趋势递增不伤数据库索引。你自己写的时候，可以留一个OrderNumberGenerator接口，后面想换实现随时换。

3.4 Service 层主流程：先把步骤写出来，再填代码

我建议动手前先在注释里把流程写清楚，再逐段实现。我当时的 Service 核心代码如下：

@Transactional(rollbackFor = Exception.class) public OrdersSubmitVO submit(OrdersSubmitDTO dto, Long userId) { // 1. 校验地址簿，必须是当前用户本人的地址 AddressBook address = addressBookMapper.getByIdAndUserId(dto.getAddressBookId(), userId); if (address == null) { throw new OrderBusinessException("地址信息不合法，请重新选择"); } // 2. 查询购物车，为空不能下单 List<ShoppingCart> cartList = shoppingCartMapper.listByUserId(userId); if (cartList == null || cartList.isEmpty()) { throw new OrderBusinessException("购物车为空，不能下单"); } // 3. 汇总金额并校验菜品状态 BigDecimal totalAmount = BigDecimal.ZERO; for (ShoppingCart item : cartList) { if (item.getDishId() != null) { Dish dish = dishMapper.getById(item.getDishId()); if (dish == null || DishStatus.UNAVAILABLE.equals(dish.getStatus())) { throw new OrderBusinessException("菜品" + item.getName() + "已停售，请重新下单"); } } totalAmount = totalAmount .add(item.getAmount().multiply(BigDecimal.valueOf(item.getNumber()))); } // 4. 生成订单主表，保存地址快照 Orders order = new Orders(); order.setNumber(buildOrderNumber()); order.setUserId(userId); order.setStatus(OrderStatus.PENDING_PAYMENT); order.setPayStatus(PayStatus.UNPAID); order.setAmount(totalAmount); order.setConsignee(address.getConsignee()); order.setPhone(address.getPhone()); order.setAddress(address.getProvince() + address.getCity() + address.getDistrict() + address.getDetail()); order.setOrderTime(LocalDateTime.now()); order.setRemark(dto.getRemark()); ordersMapper.insert(order); // 5. 生成订单明细列表 List<OrderDetail> detailList = new ArrayList<>(); for (ShoppingCart item : cartList) { OrderDetail detail = new OrderDetail(); detail.setOrderId(order.getId()); detail.setDishId(item.getDishId()); detail.setSetmealId(item.getSetmealId()); detail.setName(item.getName()); detail.setImage(item.getImage()); detail.setAmount(item.getAmount()); detail.setNumber(item.getNumber()); detailList.add(detail); } orderDetailMapper.insertBatch(detailList); // 6. 清空购物车 shoppingCartMapper.cleanByUserId(userId); // 7. 返回下单成功信息 OrdersSubmitVO vo = new OrdersSubmitVO(); vo.setId(order.getId()); vo.setOrderNumber(order.getNumber()); vo.setOrderAmount(order.getAmount()); vo.setOrderTime(order.getOrderTime()); return vo; }

这段代码有两点我想特意说明。

第一，事务加在最外层的 submit 方法上。如果我在 Controller 里调 service，事务就加在 service 的 public 方法上，这样整个步骤 1 到步骤 6 全部在一个事务里，任何一步抛异常，订单、明细、购物车都会回滚到最初状态。

第二，金额计算放在校验菜品状态循环里顺手就做了，不要先算一次、再单独循环一次。这种"一体两用"的循环能少一次全表遍历，代码也更紧凑。

3.5 Mapper 的两个关键 SQL：批量插入与条件更新

批量插入订单明细，MyBatis 里用 foreach：

<insert id="insertBatch"> INSERT INTO order_detail (order_id, dish_id, setmeal_id, name, image, amount, number) VALUES <foreach collection="list" item="item" separator=","> (#{item.orderId}, #{item.dishId}, #{item.setmealId}, #{item.name}, #{item.image}, #{item.amount}, #{item.number}) </foreach> </insert>

清空购物车，注意一定要带上 userId：

<delete id="cleanByUserId"> DELETE FROM shopping_cart WHERE user_id = #{userId} </delete>

购物车清空这个操作，很多人容易忘了带 user_id 条件，导致把别人的购物车也清了。这种低级错误通常只在测试时发现，排查起来特别看心态。所有涉及用户数据的 SQL，都强制带 user_id，这是写业务代码的基本素养。

4. 金额重算、库存防超卖、事务边界：三个容易翻车的细节

4.1 金额永远不要信前端，BigDecimal 才是朋友

很多第一次做订单的人会问：前端下单页明明已经算了总价，直接传给我存起来不就行了？

不行。订单金额一旦被恶意篡改，轻则报表对不上，重则造成实质资金损失。正确的做法是后端完全重新计算：拿购物车里的单价乘数量累加，得到订单总额。

计算时注意一个基本问题：金额字段全程用 BigDecimal，不要用 double。0.1 加 0.2 用 double 算会出现一长串浮点误差，存进数据库以后对不上账，排查成本极高。购物车表的 amount 我用的是 DECIMAL(10,2)，Java 实体对应 BigDecimal，从源头就避开精度问题。

如果你做得更严谨，还可以在提交时拿购物车快照价去比对菜品表当前价，如果价格变了，提示用户"部分菜品价格已更新，请重新确认"。学习项目里不强制要求，但接口结构上你完全可以预留这个判断。

4.2 库存扣减：先查再扣是错的，条件更新才对

下单要扣库存，这是绕不开的。初学者的写法通常是这样：

Dish dish = dishMapper.getById(item.getDishId()); if (dish.getStock() >= item.getNumber()) { dishMapper.decreaseStock(item.getDishId(), item.getNumber()); }

这个写法在并发场景下有问题：两个请求同时读到 stock = 1，都判断库存够，然后都执行扣减，最终库存变成 -1，超卖了。

正确做法是把"检查库存"和"扣减库存"合并成一条条件更新 SQL，数据库层面保证原子性：

int updated = dishMapper.decreaseStockWithCheck(item.getDishId(), item.getNumber()); if (updated == 0) { throw new OrderBusinessException("菜品" + item.getName() + "库存不足"); }

对应 SQL：

UPDATE dish SET stock = stock - #{number} WHERE id = #{id} AND status = 1 AND stock >= #{number}

这条 SQL 的意思是：只有当前库存不小于购买数量时，才允许执行扣减。受影响行数为 0 就说明库存不够或者菜品已停售，直接抛异常回滚事务。

学习项目里的菜品表不一定有 stock 字段，有的版本只做上下架状态判断。那你至少要把status = 1这个条件带上，保证不会给下架菜品下单。我建议自己练习时加上库存字段，体验一下真正的"条件扣减"写法，这个思路在秒杀、抢购、库存系统里是通用的。

4.3 @Transactional 不是万能：我遇到过的几种失效场景

下单这种多步写操作，没有事务是万万不行的。但@Transactional加上去不代表一定生效。我实际排障时遇到过的失效场景，整理成了一张表：

我的 Service 里加的是@Transactional(rollbackFor = Exception.class)，这样连受检异常也一并回滚。接单、派单、退款这些后续模块，都按同样的姿势写，保持风格统一。

另外强调一句：事务不是越界越好。把耗时的远程调用、消息推送、文件上传放进事务里，会让数据库连接长时间被占用，并发一高就出问题。下单事务里只做纯数据库操作，像"下单成功发送短信"这类动作，放到事务提交后再执行。

5. 实测排障：重复下单、售罄遗留和订单半截的排查全程

5.1 前端双击导致重复订单，后端怎么兜底

第一次联调时，我在测试环境点了一遍提交按钮，等接口响应的时间里手又点了一下，结果后端生成了两笔一模一样的订单。这个问题的根因不在前端，在后端缺少幂等处理。

最简单的方案是"一次性请求标识"：前端在下单页初始化时请求一个唯一的 requestNo 存到 Redis，提交订单时带上，后端用setIfAbsent判断这个 requestNo 是否已经被用过：

Boolean success = redisTemplate.opsForValue() .setIfAbsent("order:submit:" + userId + ":" + dto.getRequestNo(), "1", Duration.ofSeconds(30)); if (Boolean.FALSE.equals(success)) { throw new OrderBusinessException("订单正在提交中，请勿重复操作"); }

setIfAbsent是原子操作，多个并发请求同时到达时只有一个能拿到 true，其余全部走异常分支。为什么加 30 秒过期？因为如果事务失败回滚了，这个 key 还能自动释放，不会把下单渠道堵死。

学习项目没强制要求幂等，但你在真实项目里一定会遇到。我的建议是：哪怕课程不要求，也把这条记在心里，这是订单系统和高并发系统的必修课。

5.2 菜品已经售罄，购物车还残留，提交时才暴露

跟着苍穹外卖的流程走，你会发现购物车里加了一个菜品，过一会商家把它下架了，你再提交订单，接口应该怎么处理？我的处理是：下单前逐个校验菜品状态和库存，遇到停售的直接把整个下单请求抛异常，并给出明确提示，而不是悄悄跳过这个菜品继续下单。

if (dish == null || dish.getStatus() != 1) { throw new OrderBusinessException("菜品【" + item.getName() + "】已下架，请先在购物车移除后重新提交"); }

提示信息要具体到是哪个菜品，方便用户去购物车操作。更完善一点的做法是把异常信息返回到前端弹窗，让用户选择"去购物车修改"还是"删除下架商品后再下单"。课程里做个提示就够，但思路要通。

5.3 订单"半截"了，怎么一步步定位

有段时间测试反馈：订单表里多了一条记录，但订单明细表里对应的明细查不到，购物车也没清空。一看就是事务没生效，或者某一步代码没有抛异常。

我的排查顺序是这样的：

1. 先看接口日志，找到这次下单对应的订单号，确认请求是否完整走完。
2. 查 orders 表，看有没有订单记录，状态是什么。
3. 查 order_detail 表，按 order_id 查明细是否存在。
4. 查 shopping_cart 表，看购物车清空了没有。
5. 对照上面四个结果，落在哪个环节断了，就去查那一段代码。

那次问题最终定位在"异常被 catch 住没有重新抛出"。我在 Service 里写了 try-catch 打印日志，却没往外抛，导致 MyBatis 插入明细失败后，事务照常提交了主表记录。这就是事务失效的典型场景。

以后凡是这种多表联动操作，我建议日志里把核心节点都打出来，包括订单号、订单金额、明细条数、购物车清空结果。日志不丢，排障效率至少翻一倍。

6. 收尾自查：提交订单功能上线前我必跑的清单

6.1 一个实测可用的验收清单

我把提交订单模块能踩的坑都整理成了一份自查清单，每次写完这个功能，我都会对着它过一遍：

6.2 两个让我少挨骂的习惯

最后分享两个我实际养成的小习惯，也都是从踩坑里换来的。

第一个是金额和数量计算一律用 BigDecimal。这不仅针对订单金额，购物车小计、订单明细金额、退款金额统统一样。double 的精度问题不爆发则已，一爆发就是账目事故。

第二个是所有查用户数据的 SQL 都强制带 user_id 条件。购物车清空要带，地址查询要带，订单查询也要带。看起来多写一个条件，实际上挡住了大量水平越权的低级漏洞。

提交订单这个功能做完，苍穹外卖项目才算是真正进入了"交易闭环"。后面还要接支付、接派单、接订单状态流转，但核心的"数据一致性思维"就是从这里开始建立的。你把提交订单这一环做成什么样，决定了后续那些功能写起来是顺水推舟还是步步惊心。