这是一套系统化的Bug修复方案，采用测试优先策略：先复现问题…

# 订单金额Bug定位与修复指南

一、测试优先：先固化问题（复现优先于修复）

1. 编写可复现的单元测试

• 用 JUnit + 随机参数对“优惠券叠加计算”方法做模糊测试（循环上万次随机组合），捕捉到那 1/500 的失败组合后，将该组参数固化为回归测试用例。
• 构造边界用例：满减券+折扣券叠加、金额取整、0元券、跨精度金额（如 19.99）。

2. 定位可疑计算模式

常见“偶发”金额错误根源（按概率排查）：

| 可疑点 | 说明 |

|---|---|

| 浮点精度 | 用 double 计算金额，累计误差偶发触发 |

| 取整方式 | Math.round() 与四舍五入规则不一致（银行家舍入 vs 四舍五入） |

| 顺序依赖 | 多券叠加时，先折扣后满减 vs 先满减后折扣结果不同 |

| 并发读取 | 用户下单瞬间改价/改券状态，读到中间状态 |

二、逐步定位

1. 日志埋点：在计算链路各步骤打 INFO 日志（入参、每步中间金额、出参），线上开启后等错误复现，对账 500 单中的异常单。

2. 对比验证：将错误订单的入参回放到测试环境，用 BigDecimal 逐步重算，找出第一步出现偏差的位置。

3. 并发排查：检查是否有多线程/异步任务同时读写订单金额字段，MySQL 层检查是否有事务隔离级别导致脏读的窗口。

三、修复方案（按优先级）

1. 金额类型改造：全链路改用 BigDecimal（或以“分”为单位的 long），禁用 double/float。

2. 统一舍入规则：明确业务口径，统一用 BigDecimal.divide(x, 2, RoundingMode.HALF_UP)，多券叠加明确计算顺序并文档化。

3. 并发防护：下单金额计算加分布式锁或数据库乐观锁（版本号字段），防止改价与下单竞态。

4. 幂等校验：支付前做一次服务端金额重算校验，不一致则拦截。

四、回归验证与预防

• 所有历史错误订单入参作为回归用例纳入 CI。
• 补充属性级测试（如 jqwik）：校验“任何券组合下，实付金额 ≥ 0 且 ≤ 原价”等不变式。
• 上线后灰度观察一段时间，对账系统每日比对计算结果，确保错误率降为 0。