金融场景金额运算须用BigDecimal(String)无损构造、setScale(2, HALF_EVEN)统一舍入、前后端字符串传输防精度污染。
金融场景下处理浮点数加减，核心不是“避免用浮点数”，而是“不让浮点数直接参与关键计算”。真实业务中，金额变量常来自接口、数据库或用户输入，原始类型可能是 double、float 或字符串，但只要进入加减逻辑，就必须立即转为高精度表示——否则误差会累积、放大，最终导致对账不平。
关键原则：所有金额运算前，必须完成无损构造
Java 中最常见错误是用 BigDecimal(double) 直接构造，例如：
BigDecimal price = new BigDecimal(19.99); // 19.99 在 double 中本就不精确BigDecimal total = price.multiply(new BigDecimal(3)); // 结果不可信
正确做法是绕过 double 表示，从源头用字符串构造：
响应式金融公司HTML5网站模板
下载
响应式金融公司HTML5网站模板是一款适合提供家族财富管理、节税互助基金、保险投资、节税投资、财务策划和在线投资计划等服务的金融公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
- 接收前端传来的金额字符串（如
"19.99"），直接传入BigDecimal(String) - 若只能拿到 double，先转成规范字符串：
new BigDecimal(Double.toString(d))，不能用String.valueOf(d)（可能带科学计数法） - 数据库字段建议定义为
DECIMAL(18,2)，JDBC 读取时用ResultSet.getBigDecimal()，跳过 double 中间层
加减操作必须指定舍入规则
金融场景不允许默认截断或四舍五入到任意位数。例如订单总价加运费再减优惠券，每一步都需明确保留两位小数且采用银行家舍入（四舍六入五成双）：
- 使用
setScale(2, RoundingMode.HALF_EVEN)，这是《支付结算办法》和多数会计准则推荐模式 - 不要在中间步骤反复 setScale；应在最终展示或落库前统一处理，避免多次舍入叠加误差
- 示例：
total.add(freight).subtract(coupon).setScale(2, RoundingMode.HALF_EVEN)
警惕隐式类型转换和链式陷阱
实际代码中容易忽略的坑：
- 用
long存金额（单位：分）虽安全，但一旦和double运算（如折扣率0.95），就会触发隐式转 double → 精度污染 - MyBatis 的
@Select返回Double字段，未配置 typeHandler，自动转成 double → 构造 BigDecimal 时已晚 - Spring Boot 接收 JSON 时，若未配置
spring.jackson.deserialization.use-big-decimal-for-floats=true，金额字段会被反序列化为 double
前端与后端协同防错
后端再严谨，前端传错原始值也白搭：
- 前端提交金额必须校验格式：正则
/^\d+(\.\d{1,2})?$/，拒绝"19.990"或"19." - 禁止前端做任何金额加减（如实时计算满减），全部交由后端幂等接口完成
- 前后端约定金额字段统一用字符串传输（JSON 中
"amount": "299.00"），彻底隔离 number 类型
