BigDecimal精确除法技巧解析

在Java金融开发中，BigDecimal的除法计算绝非简单调用divide()即可，其设计初衷是拒绝隐式舍入——遇到10÷3这类无限循环小数时会直接抛出ArithmeticException，而非妥协于“默认四舍五入”；正确做法必须显式指定精度（scale）和舍入模式（如RoundingMode.HALF_UP），中间计算建议采用高精度（如scale=6）以避免误差累积，仅在最终落库或展示前统一缩至2位；同时务必前置校验除数非null且非零（推荐用signum()==0而非equals(BigDecimal.ZERO)），并根据业务场景谨慎选择divideToIntegralValue()（截断取整）、divideAndRemainder()（需商余双结果）等替代方案——一次参数疏忽，可能埋下跨月结息、对账偏差甚至审计风险的隐患。

BigDecimal.divide() 为什么直接用会抛 ArithmeticException

因为 BigDecimal 默认除法不接受无限循环小数，比如 10.divide(new BigDecimal("3")) 会直接炸——不是 bug，是设计：它拒绝隐式舍入。金融场景里，“默认四舍五入”这种事不能由框架替你决定。

必须显式传入两个参数：scale（保留几位小数）和 RoundingMode（怎么舍入）。漏掉任一个，就报 java.lang.ArithmeticException: Non-terminating decimal expansion。

• 常见错误现象：divide() 单参数调用、或只传 scale 没传 RoundingMode
• 正确写法示例：amount.divide(divisor, 2, RoundingMode.HALF_UP)
• RoundingMode.HALF_UP 是金融最常用模式（日常说的“四舍五入”），但注意它和数学上的“四舍六入五成双”不同

scale 设多少才安全？别硬写 2 就完事

小数位数不是拍脑袋定的。人民币金额要两位，但中间计算过程可能需要更高精度（比如利率按日计息再年化），否则累积误差会进账。

例如：本金 100 元 × 年利率 3.85% ÷ 360 × 90 天，如果每步都 .setScale(2, HALF_UP)，结果会偏移；应该只在最终展示/落库前统一缩放到 2 位。

• 推荐做法：中间运算用足够高精度（如 scale = 6 或更高），最后一步再 setScale(2, HALF_UP)
• 避免在循环里反复 setScale，性能差且易误舍入
• 注意数据库字段精度（如 MySQL 的 DECIMAL(19,4)），scale 要 ≤ 字段定义的小数位数

除零异常和 null 值比想象中更早出现

BigDecimal.divide() 遇到 divisor.equals(BigDecimal.ZERO) 会立刻抛 ArithmeticException，但很多人忘了检查 null——divide(null) 报的是 NullPointerException，堆栈还藏得深。

• 务必在调用前判空：if (divisor == null || divisor.signum() == 0)
• signum() == 0 比 equals(BigDecimal.ZERO) 更安全，能覆盖 -0.00 这种边界值
• 不要依赖 try-catch 捕获除零，那是运行时错误，该拦在逻辑入口就拦住

用 divideToIntegralValue() 还是自己 trunc？看你要不要余数

如果只是取整（比如算可买多少支基金），divideToIntegralValue() 是专为此设计的，它返回商的整数部分，且不抛无限小数异常——但它不处理小数位舍入，就是简单截断（类似 Math.floor 对正数的效果）。

• 要整数结果 + 四舍五入？别用它，老实用 divide(...).setScale(0, HALF_UP)
• 要商和余数都要？用 divideAndRemainder()，返回 BigDecimal[2] 数组，第一个是商，第二个是余数
• divideToIntegralValue() 的 scale 继承被除数，不自动归零，这点容易被忽略

金融系统里，一次除法背后往往连着会计校验、对账阈值、审计留痕，scale 和 mode 写错一位，可能三个月后才在跨月结息时暴露。别省那两行参数。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《BigDecimal精确除法技巧解析》文章吧，也可关注golang学习网公众号了解相关技术文章。