避免Java金融高精度计算陷阱的关键是切断double进入金额运算链的路径，须从字符串构造BigDecimal、阻断JSON/数据库double中间层、杜绝隐式类型转换，并统一在最终结果处用HALF_EVEN舍入。
避免Java金融高精度计算中浮点数强转陷阱，关键不是“少用double”，而是切断double进入金额运算链的路径。一旦数值以double形式出现，精度已在源头丢失，后续任何BigDecimal操作都只是在错误基础上修修补补。
严格禁止用double构造BigDecimal
这是最常见也最致命的错误：
- ❌
new BigDecimal(19.99)—— 19.99在double中本就是近似值（如19.989999999999998），构造即失真 - ✅ 正确做法：从字符串源头控制，
new BigDecimal("19.99") - ⚠️ 若只能拿到double变量d，必须先转规范字符串：
new BigDecimal(Double.toString(d))；不能用String.valueOf(d)（可能输出"1.23E-4"）
阻断JSON与数据库中的double中间层
前后端和存储环节极易悄悄引入double：
- Spring Boot反序列化：配置
spring.jackson.deserialization.use-big-decimal-for-floats=true，让Jackson直接把JSON数字字段转为BigDecimal - MyBatis读库：数据库字段定义为
DECIMAL(18,2)，Java侧用ResultSet.getBigDecimal()，跳过getDouble()再转BigDecimal的坑 - 前端传参：约定所有金额字段为字符串，如
{"amount": "299.00"}，后端Controller直接接收@RequestBody Map<String, String>或自定义DTO中金额字段声明为String
警惕隐式类型转换污染
看似安全的操作，可能暗藏double强转：
立即学习“Java免费学习笔记（深入）”；
- 折扣率计算：
long amountInCents = 1999L;×double discountRate = 0.95;→ 触发long → double隐式转换，精度立即污染 - 解决方法：将折扣率也字符串化，用
BigDecimal.valueOf(95).divide(BigDecimal.valueOf(100))参与运算 - MyBatis XML中避免
<result property="price" column="price" javaType="java.lang.Double"/>，改用java.math.BigDecimal
统一舍入时机与规则，不依赖中间截断
多次setScale会叠加误差，必须收敛到最终一步：
- ❌ 错误链式调用：
price.setScale(2).multiply(qty).setScale(2).add(tax).setScale(2) - ✅ 正确写法：
price.multiply(qty).add(tax).setScale(2, RoundingMode.HALF_EVEN) - HALF_EVEN（银行家舍入）是金融结算标准，避免系统性偏高或偏低，比HALF_UP更符合会计准则
