GitHub仓库

订单创建到底为什么这么繁琐？

前端开发者常常抱怨：点击“提交订单”只要把购物车列表发给后端就行了为什么后端不能直接把前端传来的价格、标题、总金额写进数据库？答案在于交易安全与一致性。

痛点 1：前端传递的数据不可信——价格可被篡改、商品可能已下架、库存可能已被抢完；若直接写入，使用者付费后可能发现无货。

痛点 2：没有事务会出现半成功状态——订单写入成功但库存未锁定、库存锁定但订单项保存失败等，导致数据不一致。

接口设计这方面，只需 Idempotency-Key

@PostMapping public ResponseEntity createOrder String idempotencyKey)

前端只需要提供唯一请求标识（Idempotency-Key)；怎么说呢，价格、商品信息均由服务端从数据库重新查询。说起来，这样即使前端请求被重试。也能保证同一次业务操作只产生一个订单。

痛点 3：如果后台依赖前端传递的 totalAmount 或 userId，恶意使用者可以通过伪造请求窃取他人账户或支付错误金额。

@Transactional 的真正意义

• @Transactional
• • 写入 mall_order 主表
  • 批量扣减 available_stock 并累加 locked_stock
  • 写入 mall_order_item 快照
  • 删除已结算的购物车项
• 如果任一步失败，全部回滚。保证No dirty data/no half‑success states.

库存锁定机制详解

UPDATE mall_product_sku

SET availablestock = availablestock - #{quantity},lockedstock = lockedstock + #{quantity},version = version + 1,updatedat = CURRENTTIMESTAMP
WHERE id = #{skuId}
AND available_stock>= #{quantity}

• available_stock <-> locked_stock： 可售库存转为待支付锁定库存。
• WHERE available_stock>= quantity： 保证检查+更新是单原子操作，避免并发超卖。
• 返回行数判断： 影响行数为0说明库存不足或条件失效，引发异常回滚。按理说，

为什么要保存订单快照？老实说，

• - 商品标题、SKU码、规格、单价都拷贝到 mall_order_item 表。而不是每次查询当前商品表。这样即使商品改名或降价，历史订单仍保留原始交易事实。
• - 前端误解：如果直接读取商品表。每次查看历史订单时都会看到最新数据，导致对账混乱。

幂等键设计与实现细节

正则校验： Pattern.compile 验证长度与字符集以防碰撞或非法存储。数据库唯一索引：

UNIQUE KEY uk_mall_order_user_idempotency 

"为什么不用全局唯一索引？": 全局唯一索引会限制不同使用者使用相同 key 而导致冲突；说起来，业务逻辑上，同一键仅在同一使用者下重复即可。所以按组合更合理且性能更好。

前端开发者常见误区 & 对策建议

• "提交总金额给后台": 前端估算金额仅供展示；怎么说呢，实际金额必须由后端重新计算以防篡改。
• "让前端决定 userId": 使用者身份必须来自 JWT/Session，而不是请求体。
• "先检查库存再普通更新": 并发环境会出现两次检查都认为足够而导致超卖。
• "把购物车总价当作订单总价": 两者之间可能存在时间差异，如商品降价或下架。
• "每次查询动态读商品表": 历史订单应基于快照，不随当前商品变化而变动。
• "每次重试换新幂等键": 重试时应复用相同键，否则会产生新订单。
• "取消/支付不考虑锁定库存": 必须根据支付状态释放或确认 locked_stock，以保持正确可售库存计数。

完整链路图示

sequenceDiagram participant U as 使用者 participant FE as 前端页面 participant C as OrderController participant F as OrderFacade participant T as OrderCreateTransactionService participant Cart as mall_cart_item participant SKU as mall_product_sku participant O as mall_order / mall_order_item 从U->-FE来看，点击提交订单 FE->-C这方面，POST /api/orders + Authorization + Idempotency-Key C->-F的观点是，createOrder 至于F->-F，获取 currentUserId 并校验幂等键格式 再看F->-O，查询同使用者同幂等键是否已有订单 alt 已存在 再看O-->F，返回现有订单信息 F-->C这方面，返回 OrderResponse else 不存在 再看F->-T，createOrder T->-Cart:listCheckedByUserId T->-SKU:listExistingByIds 从T->-O来看，createOrder主表 T->-SKU:update lockStock 至于T->-O。createOrderItem快照 T->-Cart:removeCheckedByUserIdAndIds 说到T-->F，return orderId 再看F-->C，return OrderResponse end C-->FE的观点是，Created + OrderResponse

事务边界示意图

stateDiagram-v2 --> Available : 商品上架 & 可售 Available --> Locked : 创建待支付订单 lockStock Locked --> Sold : 支付成功 confirmLockedStock Locked --> Available : 取消/超时 releaseLockedStock Sold -->

本地运行 & 验证流程

• TOKEN=JWT令牌字符串放这里'/> 1. Create order:

  $ curl -i -X POST 'http://localhost/api/orders' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Idempotency-Key: blog-order-'

  预期返回 HTTP Created 与 orderNo/PENDING_PAYMENT 等。

  常见错误 & 对策

  • 让前端提交 totalAmount → 后台必须自己算。总价来源于 SKU 单价 × 数量，不接受客户端传值。话说回来，
  • 让前端提交 userId → 后台只依据 JWT 提取当前使用者 ID。防止越权付款，老实说，创建订单不加事务 → 会出现“已写入主表但未扣库”之类的数据脏问题。 先查库存再普通更新 → 并发情况下两条请求都能通过检查，但最终只能扣到一条数量；用条件 UPDATE 才能原子化检查+更新。 把购物车金额当作订单金额 → 因为时间差导致错误折扣/缺货情况；说起来，请重新校验并计算。 查询动态读商品表 → 历史记录会跟随最新价格变动而失真；需保存快照字段并在查询时读取快照表。 幂等键每次重试换新 → 会产生新的业务操作而非重试已有操作，应复用同一 key 重试直至成功/明确失败。不过， 取消/支付不考虑锁定库存 → 锁定的 stock 必须在支付成功时确认售出。在取消/超时时释放，否则造成可售量错误。话说回来，

  者痛点提炼

  • 数据可信度 – 前面所有 “不要相信前段传值”的警告都是围绕这一点展开。不过，
  • 事务边界 – “创建待支付”是一个短事务。一旦提交就不会等待支付完成。
  • 幂等性 – 同一次业务动作不能产生多条记录，即使网络抖动也一样。
  • 快照 – 产品信息会变，但历史记录必须保持稳定。
  • 并发安全 – 条件 UPDATE 与版本号乐观锁是处理高并发关键手段。

  ---

  这篇文章摘自开源项目实践，对理解电商交易链路极具参考价值。© 2026 FullStackMall All Rights Reserved.