Java BigDecimal.divide 为什么会抛异常：非整除、舍入模式与金额验收

订单分摊场景里有个特别容易踩坑的常见操作：把总金额平分成多份。new BigDecimal("10").divide(new BigDecimal("3")) 看似只是做个10除以3的简单运算，结果却会直接抛出 ArithmeticException，因为最终结果是无限循环小数，Java 不会擅自主张帮你决定要保留多少位小数。

为什么10除以3没法得到一个普通的精确小数结果

BigDecimal 的无参 divide 方法从设计上就追求绝对精确的结果。1除以2可以得到有限小数0.5，1除以3的结果则没有尽头；如果这个API默默截断补全结果，金额会在调用方完全不知情的情况下出现偏差。因此JDK对这个API的约束很明确：遇到非有限小数结果或者除零的情况，就抛出 ArithmeticException。

import java.math.BigDecimal;

BigDecimal total = new BigDecimal("10.00");
BigDecimal people = new BigDecimal("3");

// ArithmeticException: Non-terminating decimal expansion
BigDecimal each = total.divide(people);

这时候别上来就包一层 try/catch 吞掉异常。这类异常不是偶发的网络抖动错误，本质是业务代码没有明确给出「结果要保留几位、按什么规则舍入」的规则。直接捕获异常返回0，反而会滋生更难排查的隐性金额错误。

金额计算先确定保留小数位，再选择对应的舍入模式

如果产品规则定义是「每人分到的金额保留两位小数，第三位按常规四舍五入处理」，你可以直接把保留位数和舍入模式的参数写在除法调用的地方：

import java.math.RoundingMode;

BigDecimal each = new BigDecimal("10.00")
        .divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP);

System.out.println(each); // 3.33

scale=2 代表小数点后固定保留两位，HALF_UP 代表常规五入逻辑。两个参数解决的是完全不同的问题：只写舍入模式不代表最终金额一定会保留两位，只写保留位数又没有说明中间值的舍入处理规则。面向金额的业务代码，最好把这两个参数封装到有明确语义的统一策略方法里。

static BigDecimal divideMoney(BigDecimal amount, BigDecimal divisor) {
    if (divisor.signum() == 0) {
        throw new IllegalArgumentException("分摊人数不能为 0");
    }
    return amount.divide(divisor, 2, RoundingMode.HALF_UP);
}

如果你的系统金额单位是分而不是元，也可以先把元转成整数分做分摊计算；但这只是改变了存储处理策略，依然不能替代余数分配的业务规则定义。

HALF_UP、HALF_EVEN 和 UNNECESSARY 该怎么选

比如发票金额这类绝对不能偷偷损失精度的场景，你可以主动用 UNNECESSARY 做精度校验门禁：

BigDecimal exact = new BigDecimal("12.00")
        .divide(new BigDecimal("4"), 2, RoundingMode.UNNECESSARY); // 3.00

BigDecimal rejected = new BigDecimal("10.00")
        .divide(new BigDecimal("3"), 2, RoundingMode.UNNECESSARY); // ArithmeticException

这类异常本身是有正向价值的：它主动告诉调用方必须先明确余数的处理规则，而不是把存在误差的错误金额直接往后传给结算链路。

把除数为零和余数分配写成明确的显式规则

指定舍入模式只能解决「单笔结果显示多少位」的问题，没法自动保证「所有分项结果加起来的总和等于原始总金额」。10.00元平分成3份得到3.33、3.33、3.34，最后一分钱应该分给谁，需要按订单行顺序、用户权重或者最大余数这类事先约定的业务规则来定。

static List split(BigDecimal total, int count) {
    if (count  result = new ArrayList();
    for (int i = 0; i 

示例里把余数全部分配给最后一位用户，只是一个可验证的参考规则，不一定适配所有业务场景。核心逻辑是分摊完成后要把所有结果重新求和，校验总和等于原始总金额，并且在接口文档里明确说明余数的归属规则。

一组最小验收测试用例

下面几类断言就能把API边界和业务规则分开做完整校验：

• 12.00 / 4 在 UNNECESSARY 下运行成功，结果为 3.00。
• 10.00 / 3 在无参 divide 下抛出 ArithmeticException。
• 10.00 / 3 采用 scale 2 和 HALF_UP 得到 3.33。
• 除数为 0 时在业务层返回明确的用户错误提示，不要把底层原生异常直接透传给前端用户。
• 分摊结果逐项求和后和原金额比对，统一保留位数，不允许隐藏一分钱的隐性差额。

assertEquals(new BigDecimal("3.33"),
        new BigDecimal("10.00").divide(
                new BigDecimal("3"), 2, RoundingMode.HALF_UP));

assertThrows(ArithmeticException.class, () ->
        new BigDecimal("10.00").divide(new BigDecimal("3")));

assertThrows(ArithmeticException.class, () ->
        new BigDecimal("10.00").divide(
                new BigDecimal("3"), 2, RoundingMode.UNNECESSARY));

常见问题

为什么BigDecimal.divide有时候运行正常、有时候会抛ArithmeticException？

无参版本的divide方法要求最终结果必须能被精确表示。1除以2的结果是有限小数所以正常，1除以3做不到完全精确就抛异常；除数为0的时候也会直接失败。

只传RoundingMode.HALF_UP参数就足够了吗？

还要明确指定保留小数位scale。金额类场景通常需要固定小数位数，调用 divide(divisor, scale, roundingMode) 重载方法逻辑会更清晰。

金额分摊该用HALF_UP还是HALF_EVEN？

跟着产品或者财务制定的规则走。面向普通用户的常规四舍五入场景一般用HALF_UP；如果业务规则要求减少大量半数舍入带来的累计偏差，就选用HALF_EVEN，同时补充对应的样例测试用例。

catch ArithmeticException之后直接返回零可以吗？

非常不推荐。先区分出除零、非整除、不允许舍入三类不同的异常原因，再返回可定位的业务错误提示，或者走事先定义好的明确分摊策略。

把精度规则变成接口契约的一部分

BigDecimal.divide 抛出异常本质是在提醒开发者：除法运算的结果从来不是只有一个数字，还附带了精度、舍入模式、余数归属这几重隐含约定。把保留小数位、RoundingMode、除零处理逻辑和总和校验逻辑一起写到业务方法和单元测试里，结算代码才不会依赖调用方的默认猜测逻辑。