直接改造价格引擎底层逻辑更治本：须清洗字符串型价格字段、防范浮点数精度溢出、补全边界校验；统一用bigdecimal强制转换并显式控制精度与舍入；关键校验嵌入构造器不可绕过。
直接改价格引擎的底层逻辑，比加补丁更治本。老旧系统里价格计算常混着字符串拼接、隐式类型转换、硬编码折扣系数，一改就崩。强制转换加边界检查不是炫技，是给混乱的价格流装上“安全阀”和“校准尺”。
先识别三类典型价格失真源头
重构前得知道病根在哪：
- 字符串型价格字段未清洗：数据库里存的是"¥299.00"或"299元"，Java里直接parseDouble会抛异常，或被截断成299.0；
- 浮点数精度溢出：用double做满减叠加（如99.99 × 0.85 × 0.95），小数位漂移导致最终价格与前端展示不一致；
- 边界缺失导致越界计算：优惠券面额大于商品原价时，未限制最低支付金额为0，出现-12.5元订单。
用 BigDecimal 强制转换 + 显式精度控制
所有价格参与运算前，必须统一转为 BigDecimal，且指定舍入模式和小数位数。不要依赖数据库字段类型或前端传参格式：
- 从请求参数获取价格时，用
new BigDecimal(request.getParameter("price").replaceAll("[^\d.-]", ""))剥离干扰字符； - 数据库读取后立即调用
setScale(2, RoundingMode.HALF_UP)固定两位小数； - 所有乘除运算必须用
multiply()/divide()方法，显式传入MathContext.DECIMAL32防止精度失控。
在关键节点嵌入不可绕过的边界校验
校验不是写在Service里可被跳过的逻辑，而是封装进价格对象构造器或工厂方法中：
- 创建
Price实体时，构造函数内强制检查：if (value.compareTo(BigDecimal.ZERO) - 优惠计算后，调用
clampToZero()方法确保结果 ≥ 0； - 多级优惠叠加（如满减+会员折扣+红包）需在组合器中校验每层输出是否在合理区间，例如会员折扣率必须 ∈ [0.5, 0.95]，超限自动截断并记录告警日志。
把校验逻辑下沉到数据访问层
避免业务代码重复写 if 判断。在 MyBatis 的 TypeHandler 或 JPA 的 AttributeConverter 中，统一处理入库/出库时的价格转换与校验：
- 出库时：将数据库 numeric 字段转为
Price对象，自动执行setScale(2)和非负校验； - 入库时：若传入
Price对象值为 null 或非法，直接拒绝持久化并抛出受检异常； - 配合数据库 CHECK 约束（如
CHECK (price >= 0 AND price ），形成双保险。
不复杂但容易忽略——真正的稳定性，藏在每一次类型转换的明确声明里，和每一处边界的无声拦截中。
