这篇解决什么问题

上一章讲到。点击“提交订单”后后端会创建待支付订单，保存订单项快照，并把 SKU 的可售库存转为锁定库存。此时交易还没有结束，只是进入了一个中间状态：使用者还没真正支付，库存也还没真正卖出。这个阶段很像前端页面里“正在支付中”的 loading 状态，但后端语义更复杂：订单不能永久停在待支付。支付结果可能来自外部网站回调，回调可能重复到达，使用者也可能主动取消订单，定时任务还可能把超时订单关闭。

本项目把这一阶段拆成几个接口和后台任务：

• 使用者登录后可以调用 POST /api/orders/{orderId}/payments 创建支付流水。
• 调用 GET /api/orders/{orderId}/payment 查询支付流水。
• 模拟外部支付网站调用 POST /api/mock-payments/callback 通知支付成功。
• 程序定时任务 OrderCloseScheduler 周期扫描超过 expires_at 的待支付订单，并调用关单事务释放库存。

这些入口虽然不同。但最终都围绕同一组主要资源：mall_ordermall_paymentmall_order_itemmall_product_sku.

本篇要解决的关键问题

1. 为什么创建支付流水和创建订单是两个接口，而不是订单创建时直接支付；
2. mall_payment 表保存什么为什么一张订单只允许一条支付流水；老实说，
3. 支付回调为什么不使用使用者 JWT。而使用 X-Mock-Payment-Secret;
4. 支付回调为什么必须幂等，重复回调为什么不能重复确认库存；
5. 支付成功时 locked_stock 如何真正变成已售库存；
6. 取消订单和超时关单如何把 locked_stock 释放回 available_stock;按理说，
7. 支付回调、取消订单、超时关单之间为什么会竞争。代码如何用锁和条件更新控制状态；按理说，

用前端知识类比

支付页不是交易终点。只是等待外部结果

Pain point： 前端同学常误以为页面的“成功”按钮就等同于业务已经完成，从而尝试自行修改订单状态。

// 前端侧示意代码：只用于解释支付页交互，不代表仓库中存在真实前端源码
async function pay {
const payment = await request.post;openMockPayPage;按理说，startPollingPayment;}
async function startPollingPayment {
const timer = setInterval => {
const res = await request.get;if {
clearInterval;话说回来，router.push;
}
if {
clearInterval;showToast，}
},2000);}

这段前端代码里页面只是在轮询后端的状态变化。真正把状态从 PENDING → SUCCESS/ CLOSED  的，是后端收到第三方网站回调后的事务处理。前端只能观察，绝不能自行声明“我已经付款”。如果前端直接改库，会导致安全漏洞还有数据不一致。

回调像前端事件。但不能只处理一次就算了

Pain point： 很多人认为一次回调足够，忽略了网络抖动或网站重发导致的重复请求。

// 前端侧示意代码：UI 事件回调通常只影响当前页面状态
thirdPartySdk.on => {
paymentStatus.value = 'SUCCESS';})，

后端必须考虑以下情况：

• 相同回调因网络超时被网站重发。

本项目采用三层幂等手段：

1. Pessimistic lock : 在处理之前先锁定对应的付款记录行，让并发请求排队。
2. If payment row is already SUCCESS。return it directly.
3. A unique index on manual_payment.callback_id,防止同一个 callback ID 被写入不同的付款记录。

超时关单像前端定时器。但执行在服务端

Pain point： 前端倒计时不可靠——使用者关闭浏览器、切换设备或网络掉线都会导致倒计时失效，却仍然期待它能真正关闭订单。

// 前端侧示意代码：倒计时只是展示，不代表订单真的被关闭
const remainSeconds = computed => expiresAt - Date.now);if {
showToast;}

真正的超时关单必须由后端定时任务完成。本项目使用 Spring 的 @Scheduled  实现。每隔固定间隔扫描并批量关闭已过期且仍为 PENDING_PAYMENT 的订单，接下来释放锁定库存。话说回来，

说到支付流水。订单和支付网站之间的桥梁 Pain point： 若把所有信息都塞进 Order 表，一旦出现多次付款尝试或退款场景，将导致表结构臃肿且难以维护。

The payment table holds:

为了保证“一张 order 对应仅有一条 payment”，在表上建立唯一索引： sql UNIQUE KEY uk_mall_payment_order_id 这样即使多个请求并发尝试创建付款，也只能有一条插入成功。

Simplified diagram of relationship:

# Mermaid Class Diagram
classDiagram
class OrderEntity{
id
orderNo
userId
statusCode
totalAmount
expiresAt
}
class PaymentEntity{
id
paymentNo
orderId
userId
amount
statusCode
callbackId
providerTransactionNo
}
OrderEntity --> PaymentEntity : order_id unique

订单状态机与付款状态机
Pain point： 开发者常把两套状态混用，在业务流程里出现 “已付款但仍是 PENDING_PAYMENT”。按理说，

Name Description
payment_no	程序生成的唯一付款流水号。用于对接模拟网站
order_id	关联的 order id
user_id	下单使用者 id
amount	从 Order 快照中复制的应付金额
status_code	付款当前状态
provider_transaction_no	第三方网站返回的交易号
callback_id	本次回调事件唯一标识
created_at / updated_at / paid_at / closed_at	时间戳字段

OrderStatus \	PaymentStatus
PENDING_PAYMENT \	PAID \	PENDING \	SUCCESS \ ... **关系约束** 当 Order 状态变为 PAID 时对应 Payment 必须是 SUCCESS。 当 Order 被 CANCELLED 或 CLOSED 时如果对应 Payment 仍是 PENDING，则要将其改为 CLOSED。 已经 SUCCESS 的 Payment 不能 再被 CLOSE。 这套双向约束通过 **条件 UPDATE** 与 **行锁** 实现。mermaid stateDiagram-v2 --> PENDING_PAYMENT: 创建待付 & 锁库存 PENDING_PAYMENT --> PAID: 支付成功回调 PENDING_PAYMENT --> CANCELLED: 使用者主动取消 PENDING_PAYMENT --> CLOSED: 程序超时关单 PAID --> CANCELLED --> CLOSED --> mermaid stateDiagram-v2 --> PENDING: 创建 Payment 流水 PENDING --> SUCCESS: 支付成功回调 PENDING --> CLOSED: 取消或超时关闭 SUCCESS --> CLOSED -->

---