bigdecimal.setscale() 必须用 roundingmode.half_up 而非过时的整数常量，且需显式赋值新对象；setscale() 是强制设定位数而非限制最多位数，金额计算应先判断 scale 是否超限再舍入。
BigDecimal.setScale() 为什么不能直接用 ROUND_HALF_UP？
很多人一上来就写 setScale(2, BigDecimal.ROUND_HALF_UP)，结果在 Java 9+ 报错：该构造方法已过时且被移除。这不是 bug，是 API 明确弃用了整数类型的舍入模式参数。必须改用 RoundingMode 枚举——否则编译失败或运行时抛 IllegalArgumentException。
- Java 8 及以前：
setScale(2, BigDecimal.ROUND_HALF_UP)可用，但已是 @Deprecated - Java 9+：必须用
setScale(2, RoundingMode.HALF_UP)，且需 importjava.math.RoundingMode - 漏写
RoundingMode导入、或误写成BigDecimal.HALF_UP，都会编译不通过
金额计算该选 HALF_UP 还是 HALF_EVEN？
银行和财务系统普遍要求「四舍五入」，即传统意义上的 RoundingMode.HALF_UP。但 RoundingMode.HALF_EVEN（银行家舍入）会把 .5 向偶数端舍入（如 1.5→2，2.5→2），虽能降低统计偏差，却不满足多数计费场景的合规要求。
- 支付扣款、发票金额、税率计算等，一律用
RoundingMode.HALF_UP -
RoundingMode.HALF_EVEN适合科学统计、长期累加误差敏感场景，不是金额首选 - 别用
RoundingMode.UP或RoundingMode.CEILING，它们会无条件进位，导致多收用户钱
setScale() 前必须检查 scale 是否已满足要求
setScale() 不是「限制最多几位小数」，而是「强制设为指定 scale」。如果原值小数位少于目标位数（如 new BigDecimal("10") 调用 setScale(2)），会补零；但如果原值小数位更多（如 "10.123" → setScale(2)），才真正触发舍入。不加判断直接调用，可能把干净的整数变成带冗余零的 10.00，影响日志可读性或下游格式化逻辑。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 若只需「不超 2 位小数」，应先判断：
if (bd.scale() > 2) bd = bd.setScale(2, RoundingMode.HALF_UP) - 避免对已精确到分的值（如
new BigDecimal("99.99")）反复 setScale，徒增对象创建开销 - 注意：
scale()返回的是小数位数，负值表示科学计数法（如1E+2的 scale 是 -2），金额中极少出现，但做通用工具类时需防御
为什么 setScale() 后的 BigDecimal 一定要重新赋值？
BigDecimal 是不可变类型，setScale() 返回一个新对象，原变量不变。写成 amount.setScale(2, RoundingMode.HALF_UP); 而不接返回值，等于什么都没做——这是线上金额错误最隐蔽的根源之一。
- 正确写法：
amount = amount.setScale(2, RoundingMode.HALF_UP); - 链式调用更安全：
total.add(tax).multiply(rate).setScale(2, RoundingMode.HALF_UP) - IDE 通常不会警告这种「忽略返回值」行为，靠代码审查或单元测试覆盖才容易发现
金额精度问题从来不在函数怎么写，而在谁在什么时候、以什么前提调用了它。尤其当多个服务共享同一笔金额对象、或中间经过 JSON 序列化（可能丢失 scale 信息）时，setScale() 的调用时机和上下文比参数选择更关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
