huang
b02175271a
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 5m39s
- 新增企业设备授权模块（Model、DTO、Service、Handler、Store） - 实现设备授权的创建、查询、更新、删除等完整业务逻辑 - 添加企业卡授权与设备授权的关联关系 - 新增 2 个数据库迁移脚本 - 同步 OpenSpec delta specs 到 main specs - 归档 add-enterprise-device-authorization 变更 - 更新 API 文档和路由配置 - 新增完整的集成测试和单元测试覆盖
1.6 KiB
1.6 KiB
订单激活幂等性修复 - 设计
目标
- 同一订单被重复支付/重复回调/重复请求时，只会激活一次套餐使用记录。
- 重复请求返回“幂等成功”（不报错，不重复激活）。
- 避免因并发导致的重复插入。
方案
1) 以状态机作为幂等门闸
将订单支付状态从 pending 变更为 paid 时使用条件更新：
UPDATE tb_order SET payment_status=paid,... WHERE id=? AND payment_status=pending- 若
RowsAffected == 0：- 视为订单已被处理（可能已支付/已取消/已退款）
- 对“已支付”场景直接返回成功（幂等成功）
- 对“非待支付且非已支付”场景返回对应业务错误（例如已取消不允许支付）
这样可以确保并发下只有一个请求能“拿到激活资格”。
2) 激活逻辑只在首次成功支付后执行
activatePackage 只在上述条件更新成功后执行；并确保激活过程内的数据读取使用同一个事务 tx（避免出现读取不一致或部分写入）。
3) 防御性约束（可选但推荐）
为 tb_package_usage 增加唯一约束（示例）：
- 同一订单下，同一
package_id只能有一条 usage - 以
order_id + package_id为主（按当前业务：一个订单对应一个资源，且一次购买不应重复同套餐）
如果未来允许同订单同套餐多份购买，则需要同时引入 quantity 或 usage 的明细拆分策略，再调整唯一约束。
验收标准
- 重复调用钱包支付/支付回调接口，不会重复生成
tb_package_usage记录。 - 幂等重复请求返回成功。
- 新增测试通过。