做结算类需求的人，早晚都会被BigDecimal教育一次。我第一次被它教育，是因为一笔退款算出来是199.99999999999997，前端展示两位小数变成了199.99，财务那边按200.00记的账，月底对账差了整整一分钱，查了半个下午才定位到一个double类型的折扣率。BigDecimal的使用，核心就三件事：初始化怎么写才不会一开始就带着误差、赋值时那些看起来没问题的写法为什么会悄悄失效、比大小用哪个方法才不会在1.0和1.00上翻车。这篇内容面向的是刚接手金额、税率、积分、汇率这类精度敏感字段的同学，也适合已经用过但踩过坑、想把规则彻底理清楚的老手。我会把构造函数的取舍、运算的 scale 变化规律、比较方法的差异、以及工程里怎么把这些约束固化下来，一条条摊开讲。看完你至少能做到两件事：代码评审时一眼看出new BigDecimal(0.1)这种写法，以及在自己的模块里把精度问题挡在入口而不是留到对账。这不是一篇 API 罗列，是我这些年在这个类上栽过的跟头和后来形成的规矩，能直接抄去用。
1. 一分钱对不上的账：double 的坑到底从哪来
1.1 二进制浮点的先天缺陷
很多人对BigDecimal的第一印象是“精度高”，但说不清它到底在解决什么问题。根子上讲，double用的是 IEEE 754 双精度二进制浮点表示，一个数被拆成符号位、指数位和尾数位，尾数只有 52 位有效二进制位。问题在于，十进制里很多“看起来很正常”的小数，转成二进制是无限循环小数。0.1就是典型：它的二进制展开是0.0001100110011...无限循环，存进 52 位尾数就必须截断，截断产生的误差再参与运算就被放大了。
你可以自己跑一下这段代码，结果会让第一次见的人愣一下：
public class FloatDemo { public static void main(String[] args) { System.out.println(0.1 + 0.2); // 0.30000000000000004 System.out.println(1.0 - 0.9); // 0.09999999999999998 System.out.println(4.35 * 100); // 434.99999999999994 System.out.println(new java.math.BigDecimal(0.1)); // 0.1000000000000000055511151231257827021181583404541015625 } }最后一行是最有信息量的。它告诉你double里的那个0.1实际存的是0.1000000000000000055511151231257827021181583404541015625，只是Double.toString在打印时做了最短表示优化，把它“美化”成了0.1。也就是说，误差一直都在，只是平时被打印逻辑藏住了。当这个误差进入乘法、累加、四舍五入，藏不住的时候就变成了账面上的一分钱。
BigDecimal的做法是换一种表示：用一个BigInteger类型的intVal存有效数字，再用一个int类型的scale记录小数点位置，实际值等于intVal × 10^(-scale)。这套表示对十进制是精确的，0.1就是intVal=1, scale=1，不存在截断。代价是运算比原生类型慢一到两个数量级，内存占用也大，所以它只该出现在真正需要精确的场合：金额、税率、汇率、积分兑换比例、科学计算里的高精度中间结果。
1.2 三个最容易被忽略的失败场景
知道原理不够，得知道它在业务里长什么样。我总结下来，翻车最集中的是三个场景。
第一个是累加型误差。单笔金额用double算，误差在1e-15量级，看不出来；但一个批次几万笔、一天几百万笔累加下来，误差会累积到分位。我们当时那个结算模块，单笔返佣用double乘费率，跑一个月批次汇总，跟财务系统的合计差了三十多块，一开始都怀疑是丢单，最后是一行行加出来的。
第二个是阈值判断被误差击穿。比如判断“满 100 减 10”，商品价格99.99加上运费0.01，理论上正好100.00，但double算出来可能是99.99999999999999，判断失败，用户投诉活动不生效。这种问题极难复现，因为它依赖具体数值组合。
第三个是序列化和往返转换。数据库里存decimal(19,4)，读出来映射成double，再转回BigDecimal写回去，中间就过一次浮点，四位小数可能变成xxx.0000000000001。这类问题往往在数据迁移、报表导出、跨系统对接时才暴露，因为两边对同一个数的“字面值”理解不一致。
注意：判断一个字段该不该用
BigDecimal，看的不是“这个数会不会很大”，而是“这个数的最后一位是否有业务含义”。金额的最后一位是分，税率的最后一位可能是万分之一，这些都是有含义的；而温度、坐标、统计数据这类允许误差的量，double完全够用，硬上BigDecimal只会让代码变重。
1.3 为什么不用 long 存分
有人会问，既然double不行，为什么不用long存“分”？这是个好问题，也是很多团队的真实选择。long存分的好处是运算快、无精度问题、数据库友好，坏处是 scale 被写死成 2 位，遇到汇率（常见 6 位）、利率（可能 8 位）、单价（电商里 4 位很常见）就不够用了，而且每次展示都要手动除以 100，散落在各处的魔法数字特别容易漏。
我的实践是分场景：只做加减、scale 固定两位的账户余额类字段，用long存分完全可行；涉及乘除、多币种、多精度层级的场景，老老实实用BigDecimal，把 scale 和舍入规则显式写进代码。两者不要混用，一个系统里两套表示并存，转换代码会变成新的 bug 温床。
2. 初始化：五种写法，三种结局
2.1 最危险的写法：new BigDecimal(double)
BigDecimal有六个公开构造器，最容易被误用的就是接收double的那个。原因很直观：IDE 补全时你手上正好有个double变量，顺手就传进去了，编译通过，运行不报错，但对象里已经带着double的完整二进制误差。
BigDecimal bad = new BigDecimal(0.1); // 0.1000000000000000055511151231257827021181583404541015625 BigDecimal good = new BigDecimal("0.1"); // 0.1 BigDecimal also = BigDecimal.valueOf(0.1); // 0.1bad这个对象的scale是 55，intVal是一长串数字。它参与setScale(2, RoundingMode.HALF_UP)之后结果确实是0.10，看起来“没事”，但只要你在setScale之前做过一次比较、一次除法、一次equals，问题就出来了。比如bad.compareTo(new BigDecimal("0.1"))返回的不是 0，而是 1。
这个构造器的存在有它的理由——需要精确复现某个double的真实值时（比如调试数值算法），它是唯一手段。但在业务代码里，它基本等于一个 bug 标记。我现在的做法是在代码规范里直接禁掉，评审看到就打回，没有例外。
2.2 字符串构造与 valueOf 的分工
替代方案有两个，用哪个取决于你手上的原始数据是什么类型。
如果原始数据本身就是字符串——数据库decimal字段读出来的String、配置文件里的费率、前端传上来的金额——直接new BigDecimal(String)，这是最干净的一条路。字符串里写的是什么，BigDecimal里存的就是什么，不做任何额外转换。注意字符串里不能有空格、千分位逗号、货币符号，new BigDecimal("1,000.00")会直接抛NumberFormatException，这些清洗工作要放在构造之前做。
如果原始数据是double且你无法改变（比如某个第三方 SDK 只给double），用BigDecimal.valueOf(double)。它内部的实现是new BigDecimal(Double.toString(val))，先把这个double转成最短表示字符串，再用字符串构造。所以BigDecimal.valueOf(0.1)得到的就是精确的0.1。这里有个细节值得知道：valueOf拿到的是double能表示的、离原值最近的那个十进制短表示，对于0.1这类数它就是0.1；但如果这个double本身是从更高精度算出来的，valueOf只会保留 17 位左右的有效数字，超出部分的信息已经丢了。所以valueOf是“止损”，不是“还原”。
// 从数据库/配置读取，首选 BigDecimal rate = new BigDecimal("0.0001"); // 第三方只给 double，退而求其次 BigDecimal rate2 = BigDecimal.valueOf(thirdPartyRate); // 已经有 long/int 的整数分，注意 scale BigDecimal fromLong = BigDecimal.valueOf(1999L, 2); // 19.99，第二个参数是 scale最后那个BigDecimal.valueOf(long unscaledVal, int scale)是个被严重低估的方法。它等价于BigDecimal.valueOf(unscaledVal).scaleByPowerOfTen(-scale)，但走的是内部优化路径，不产生中间对象，在“分转元”这种高频转换里比new BigDecimal("19.99")快得多，也不会引入字符串解析开销。
2.3 常量、char 数组与 BigInteger 构造的适用场景
除了上面几个，还有几种构造方式，用得少但关键时刻能省事。
BigDecimal.ZERO、BigDecimal.ONE、BigDecimal.TEN是预定义常量，直接引用可以避免重复创建对象，更重要的是可读性——sum.compareTo(BigDecimal.ZERO) == 0比sum.compareTo(new BigDecimal("0")) == 0意图清晰得多。注意只有这三个，BigDecimal.TWO是不存在的，别想当然。
new BigDecimal(char[] in, int offset, int len)用在解析大段文本的场合，比如从定长报文里截取金额字段，能避免先substring再建对象的两次内存分配。这个构造器内部直接解析字符数组，性能上有优势，代价是可读性差，我一般只在高频解析的底层组件里用。
new BigDecimal(BigInteger unscaledVal, int scale)是做定点数运算时的利器。比如你想用整数运算模拟四位小数，可以全程用BigInteger算，最后一次性包成BigDecimal，避免中间步骤的scale膨胀。
2.4 scale 和 precision：初始化时就决定了后续行为
这两个概念必须在这里说清楚，因为后面所有的坑都跟它们有关。
precision（精度）是有效数字的位数，123.45的 precision 是 5。scale（标度）是小数位数，123.45的 scale 是 2，1.0的 scale 是 1，100的 scale 是 0，1E+2的 scale 是 -2（对，scale 可以是负数）。
关键点是：new BigDecimal("1.0")和new BigDecimal("1.00")是两个不相等的对象。它们的数值相同，但 scale 不同（1 和 2），equals返回false，hashCode也不同。这个特性在后面讲比大小的时候会展开，这里先记住结论：初始化时写几位小数，对象就带着几位，这个“尾巴”会一直跟着它。
| 初始化写法 | 等价数值 | scale | 是否保留末尾零 | 推荐度 |
|---|---|---|---|---|
new BigDecimal("1.50") | 1.5 | 2 | 保留 | 高，语义明确 |
new BigDecimal(1.5) | 1.5 | 1 | 不保留 | 低，带二进制误差 |
BigDecimal.valueOf(1.5) | 1.5 | 1 | 不保留 | 中，仅限 double 来源 |
BigDecimal.valueOf(150L, 2) | 1.50 | 2 | 保留 | 高，性能好 |
BigDecimal.ZERO | 0 | 0 | — | 高，常量引用 |
注意：不要试图通过
new BigDecimal("1.50")来完成“展示格式化”。格式化该用setScale或DecimalFormat，构造器只负责表达数值本身。我见过有人在构造时手动补零来凑展示效果，结果是同一个金额在系统里出现了1.5、1.50、1.500三种形态，equals全不相等，去重和分组统计全乱。
3. 赋值与运算：先把不可变这件事刻进脑子
3.1 a.add(b) 之后 a 为什么没变
BigDecimal是不可变对象，所有看似“修改”的方法都返回新对象，原对象纹丝不动。这句话所有人都看过，但真正踩过坑的人才知道它有多容易忘。
最高频的错误是这个：
BigDecimal total = BigDecimal.ZERO; for (Order o : orders) { total.add(o.getAmount()); // 错误：结果被丢弃了 } System.out.println(total); // 永远是 0正确写法必须是重新赋值：total = total.add(o.getAmount());。这个错误之所以高频，是因为它编译不报错、运行不抛异常，只是结果不对。如果这段代码是累加统计，输出 0 或者偏差巨大，还好排查；如果它嵌在某个分支里只影响一小部分数据，可能几个月都没人发现。
“赋值”这个词在BigDecimal语境下要拆成三层理解：变量赋值只是引用拷贝，两个变量指向同一个不可变对象，谁也不会影响谁；字段赋值发生在setter或构造器里，从这个时刻起，对象里存的值就固定了；运算结果赋值是最容易漏的一层，因为+ - * /这些运算符在BigDecimal上根本不可用，只能调方法，而方法返回新值这件事需要你主动接住。
顺便说一个相关的坑：BigDecimal没有重载+运算符，所以a + b编译不过，这是好事，逼你用方法名。但有些团队会用BigDecimal的add包一层变成a.add(b)写在表达式里，比如if (a.add(b).compareTo(c) > 0)，这种写法没问题，因为结果被立刻消费了。真正要警惕的只有“调用了但没接住返回值”这一种形态。
3.2 加减乘的 scale 变化规律
scale的变化不是随机的，有明确规则，记住以后能提前预判结果长什么样。
加法：结果的 scale 等于两个操作数 scale 的较大值。new BigDecimal("1.5").add(new BigDecimal("1.25"))得到2.75，scale 是 2。new BigDecimal("1.5").add(new BigDecimal("1"))得到2.5，scale 是 1。
减法：同加法，取较大 scale。new BigDecimal("1.50").subtract(new BigDecimal("1.5"))得到0.00，scale 是 2，注意它不是0。
乘法：结果的 scale 等于两个操作数 scale 之和。new BigDecimal("1.5").multiply(new BigDecimal("1.5"))得到2.25，scale 是 2。这个规则意味着乘法会让 scale 快速膨胀，一个 scale 为 6 的汇率乘上 scale 为 4 的单价，得到 scale 为 10 的结果，如果不加setScale就直接入库，decimal(19,4)字段会直接报错或被静默截断。
除法：这是唯一会让 scale 收缩也可能报错的操作，单独说。
BigDecimal a = new BigDecimal("4.35"); BigDecimal b = new BigDecimal("100"); System.out.println(a.multiply(b)); // 435.00，scale = 2 + 0 = 2 System.out.println(a.divide(b)); // 0.0435，scale = 2 - 0 = 2？ // 上面这行其实会得到 0.0435，因为能整除时结果精确 // 但换成 a.divide(new BigDecimal("3")) 就会抛异常scale会膨胀这件事在实际工程里有真实代价：一个字段如果经历“单价 × 数量 × 折扣 × 税率”四次乘法，scale 会累加到十几位，前端展示时要截、入库时要截、传给下游时还要截，每一处截断都是舍入规则的决策点。我的习惯是在每一次乘除之后立刻setScale到业务精度，而不是攒到最后统一处理，这样每个环节的舍入行为都是显式且可控的。
3.3 divide 没有默认精度：三参数写法是硬要求
divide是BigDecimal里唯一会让你运行时炸掉的方法。原因很简单：1 ÷ 3的结果是无限循环小数，BigDecimal无法精确表示，只能抛异常。
BigDecimal one = BigDecimal.ONE; BigDecimal three = new BigDecimal("3"); one.divide(three); // java.lang.ArithmeticException: Non-terminating decimal expansion; // no exact representable decimal result.这个异常消息是排查线索里信息量最大的之一，见到它基本不用想别的，就是除法没有指定精度。修法有两种：
// 方式一：指定 scale 和舍入模式（推荐） BigDecimal r1 = one.divide(three, 4, RoundingMode.HALF_UP); // 0.3333 // 方式二：指定 MathContext（精度位数，不是小数位数） BigDecimal r2 = one.divide(three, new MathContext(4, RoundingMode.HALF_UP)); // 0.3333注意MathContext里的4是有效数字位数，不是小数位数。new MathContext(4)作用在12345.678上会得到1.235E+4，作用在0.00123456上会得到0.001235。对金额场景来说，用divide(divisor, scale, RoundingMode)这种按小数位控制的方式更符合直觉，也更不容易算错。
还有一点：divide的两参数版本divide(BigDecimal, int roundingMode)是已废弃的，它接收的是int常量（BigDecimal.ROUND_HALF_UP这类），不要在新代码里用。统一用RoundingMode枚举，import java.math.RoundingMode，编译期就能做类型检查。
八种舍入模式里，业务代码真正会用到的是下面几个，其余的知道有就行：
| 舍入模式 | 行为 | 典型场景 |
|---|---|---|
HALF_UP | 四舍五入，5向上进位 | 金额展示、常规结算，最常用 |
HALF_EVEN | 银行家舍入，5取最近的偶数 | 多次累加的统计场景，避免系统性偏差 |
DOWN | 直接截断，向零方向 | 用户侧优惠计算，宁可少给不错给 |
UP | 远离零方向进位 | 成本、税费预估，宁可多算不少算 |
CEILING/FLOOR | 向正无穷 / 负无穷舍入 | 涉及正负数的区间计算 |
HALF_DOWN | 五舍六入 | 少数需要对称舍入的场景 |
UNNECESSARY | 不允许舍入，有精度损失就抛异常 | 断言“这个除法必须整除”，适合写校验 |
HALF_UP和HALF_EVEN的差别值得单独说一句。HALF_UP有个统计学上的小缺陷：被舍入的 5 永远向上，长期累加会略微偏大。HALF_EVEN让 5 交替向上向下，大量数据的合计更接近真值。财务系统里如果一天几百万笔都要舍入，这个偏差是能被审计出来的。我的做法是：单笔展示用HALF_UP（符合用户直觉），批量汇总的中间计算用HALF_EVEN（减少系统性偏差）。
3.4 setScale、stripTrailingZeros 与显示格式化
setScale是最常用的方法，作用是调整 scale。它有两种形态：单参数版本在不损失精度时成功、损失精度时抛ArithmeticException；双参数版本显式指定舍入模式。
BigDecimal v = new BigDecimal("2.345"); v.setScale(2, RoundingMode.HALF_UP); // 2.35，正常舍入 v.setScale(2); // 抛异常，因为会丢精度 new BigDecimal("2.300").setScale(2); // 2.30，没有精度损失，正常返回单参数版本的行为经常被误解：它不是“直接截断”，而是“不允许截断”。2.30变2.30没问题，2.345变2.34就不行。这个设计其实很好，逼你显式表达舍入意图，只是很多人第一次遇到异常时一脸懵。
stripTrailingZeros用来去掉末尾多余的零，2.300会变成2.3，scale 从 3 变成 1。它的常见用途是对比“数值是否相同”之前做归一化，或者入库前清理多余小数位。有个历史问题要注意：早期 JDK 里BigDecimal.ZERO.stripTrailingZeros()会返回一个 scale 为负的奇怪对象，打印出来是0E-...这种形式，较新的 JDK 已经修正。如果你在维护老系统，处理零值前先判断一下signum() == 0更保险。
显示格式化不要用toString。BigDecimal的toString在指数超过一定范围时会退化成科学计数法，new BigDecimal("1E+10").toString()得到的是1E+10而不是10000000000。要拿到“人类可读”的写法，用toPlainString()：
BigDecimal big = new BigDecimal("1E+10"); System.out.println(big.toString()); // 1E+10 System.out.println(big.toPlainString()); // 10000000000 System.out.println(big.toEngineeringString()); // 10E+9前端展示还要考虑千分位和货币符号，那是DecimalFormat或框架层的活。DecimalFormat有个经典陷阱：默认的RoundingMode是HALF_EVEN，跟业务预期的HALF_UP不一致，需要显式设置setRoundingMode(RoundingMode.HALF_UP)。我见过一个导出报表的功能，页面上显示2.35，导出 Excel 变成2.34，就是两处用了不同舍入模式。
4. 比大小：compareTo 和 equals 是两条路
4.1 equals 连 scale 一起比
BigDecimal重写了equals，实现逻辑是：scale 相等且 intVal 相等。这意味着new BigDecimal("1.0").equals(new BigDecimal("1.00"))返回false。数值上它们是同一个数，但 scale 不同，equals就认为不相等。
这个设计经常被骂，但它其实是一致性的体现：equals和hashCode必须匹配，而hashCode是用intVal和scale一起算的，如果equals忽略 scale，就会出现“两个相等的对象 hashCode 不同”的违反契约的情况，HashMap、HashSet立刻出问题。所以 JDK 选择了严格语义，把“数值相等”的判断交给compareTo。
带来了什么实际后果？最典型的是集合操作：
Set<BigDecimal> set = new HashSet<>(); set.add(new BigDecimal("1.0")); set.add(new BigDecimal("1.00")); System.out.println(set.size()); // 2，而不是 1如果你用BigDecimal做金额去重、分组统计的 key，这个行为会让结果翻倍。正确做法是入库或入集合前统一setScale(2, RoundingMode.HALF_UP)，让所有金额都是同一个 scale，从源头消除差异。这比在比较时到处写compareTo干净得多。
4.2 compareTo 的返回值别当 -1/0/1 用
compareTo是判断数值大小的正确方法，返回-1、0、1分别表示小于、等于、大于。注意文档里写的是“负整数、零、正整数”，实现上目前确实返回这三个值，但不要依赖具体数值，正确写法是跟 0 比较：
BigDecimal a = new BigDecimal("1.0"); BigDecimal b = new BigDecimal("1.00"); if (a.compareTo(b) == 0) { // 正确 System.out.println("数值相等"); } if (a.compareTo(b) == -1) { // 能跑，但不该这么写 // ... } if (a.equals(b)) { // false，因为 scale 不同 // ... }compareTo的内部实现是先比符号、再比数值，跟 scale 无关，所以1.0和1.00返回 0，100和1E+2也返回 0。这是业务代码里判断“两个金额是否相等”的唯一正确方式。
还有一个隐蔽的点：compareTo接收的参数是BigDecimal，传null会抛NullPointerException。如果比较的两个值可能来自数据库或外部输入，判空要在调用前做，不要指望它自己处理。
4.3 与零比较、区间判断、排序
跟零比较是最常见的场景，有两种写法：
BigDecimal v = getAmount(); // 写法一：compareTo if (v.compareTo(BigDecimal.ZERO) > 0) { /* 正数 */ } if (v.compareTo(BigDecimal.ZERO) == 0) { /* 零 */ } if (v.compareTo(BigDecimal.ZERO) < 0) { /* 负数 */ } // 写法二：signum，返回 -1 / 0 / 1 if (v.signum() > 0) { /* 正数 */ } if (v.signum() == 0) { /* 零 */ }signum()的语义更直接，性能也略好（不需要构造比较对象），我倾向于在纯符号判断时用它。但要注意signum()只返回符号，不能用来比两个数的大小。
区间判断要小心边界。判断“金额在 [0, 100] 之间”：
boolean inRange = v.compareTo(BigDecimal.ZERO) >= 0 && v.compareTo(new BigDecimal("100")) <= 0;不要写成v.compareTo(BigDecimal.ZERO) > -1这种，虽然结果一样，可读性差太多，评审时容易被要求改。也不要先setScale再比较，如果v是100.004，setScale(2, HALF_UP)之后变成100.00，区间判断就通过了，但它实际上超出了边界。比较用原值，展示才舍入，顺序不能反。
排序是另一个容易出问题的场景。BigDecimal实现了Comparable，Collections.sort和TreeSet走的是compareTo，所以1.0和1.00会被认为相等。如果你用TreeSet存金额做去重，得到的是“数值去重”而不是“对象去重”，这个行为跟HashSet相反，混用两个集合会导致结果不一致。我的建议很简单：需要去重的金额，先统一 scale，然后想用哪个集合用哪个。
5. 工程化落地：把用法固化成约束
5.1 一个能直接抄的工具类
零散地记住规则没用，工程上要靠封装把正确用法变成默认路径。下面这个工具类是我在多个项目里迭代出来的版本，覆盖了最常用的几个操作，重点是每个方法都强制指定 scale 和舍入模式，不给调用方留“忘记传”的机会。
import java.math.BigDecimal; import java.math.RoundingMode; public final class MoneyUtils { /** 金额统一精度：两位小数 */ public static final int MONEY_SCALE = 2; /** 费率统一精度：六位小数 */ public static final int RATE_SCALE = 6; private MoneyUtils() {} /** 安全构造：字符串入口，null 或空串返回 ZERO */ public static BigDecimal of(String val) { if (val == null || val.trim().isEmpty()) { return BigDecimal.ZERO; } return new BigDecimal(val.trim()); } /** 安全构造：long 分转元 */ public static BigDecimal ofFen(long fen) { return BigDecimal.valueOf(fen, MONEY_SCALE); } /** 元转分，四舍五入 */ public static long toFen(BigDecimal amount) { if (amount == null) { return 0L; } return amount.setScale(MONEY_SCALE, RoundingMode.HALF_UP) .movePointRight(MONEY_SCALE) .longValueExact(); } /** 加法，结果规整到金额精度 */ public static BigDecimal add(BigDecimal a, BigDecimal b) { return nullToZero(a).add(nullToZero(b)) .setScale(MONEY_SCALE, RoundingMode.HALF_UP); } /** 减法 */ public static BigDecimal subtract(BigDecimal a, BigDecimal b) { return nullToZero(a).subtract(nullToZero(b)) .setScale(MONEY_SCALE, RoundingMode.HALF_UP); } /** 乘法，用于 单价 × 数量 这类场景 */ public static BigDecimal multiply(BigDecimal a, BigDecimal b) { return nullToZero(a).multiply(nullToZero(b)) .setScale(MONEY_SCALE, RoundingMode.HALF_UP); } /** 除法，强制指定精度，杜绝 ArithmeticException */ public static BigDecimal divide(BigDecimal a, BigDecimal b) { if (b == null || b.signum() == 0) { throw new IllegalArgumentException("除数不能为零"); } return nullToZero(a).divide(b, MONEY_SCALE, RoundingMode.HALF_UP); } /** 数值相等判断，忽略 scale */ public static boolean eq(BigDecimal a, BigDecimal b) { return nullToZero(a).compareTo(nullToZero(b)) == 0; } /** 是否大于 */ public static boolean gt(BigDecimal a, BigDecimal b) { return nullToZero(a).compareTo(nullToZero(b)) > 0; } /** 是否为零 */ public static boolean isZero(BigDecimal v) { return v == null || v.signum() == 0; } /** 展示用：保留两位，返回字符串 */ public static String display(BigDecimal v) { return nullToZero(v).setScale(MONEY_SCALE, RoundingMode.HALF_UP) .toPlainString(); } private static BigDecimal nullToZero(BigDecimal v) { return v == null ? BigDecimal.ZERO : v; } }几个设计取舍值得说一下。第一，null统一转成ZERO，因为金额场景里null和 0 的业务含义几乎总是一样的，让每个调用方都判空纯属重复劳动。但divide的除数是例外，null和 0 都直接抛异常，因为“除数为零”是明确的逻辑错误，掩盖它只会让问题更晚暴露。
第二，toFen用longValueExact()而不是longValue()。前者在数值超出long范围时会抛ArithmeticException，后者会静默截断。金额字段一旦溢出，静默截断产生的错误数字比崩溃难查一百倍，我宁可让它炸。
第三，所有运算方法内部都做了setScale。这会让中间结果失去一些精度，但换来的是“任何经过工具类的金额都是两位小数”这个强不变量。在业务系统里，这个不变量比多保留几位小数有价值得多。真正需要高精度中间值的场景（比如利息计算、汇率换算），我会单独走一条不setScale的路径，并且在那条路径上明确注释“此处保留原始精度，最终由 XX 方法统一舍入”。
5.2 金额字段的数据库与序列化约定
代码写对了，数据在存储和传输环节掉链子的情况一点不少。
数据库层面，金额字段用DECIMAL(19,4)或DECIMAL(19,2)，不要用FLOAT或DOUBLE。MySQL 的DECIMAL是精确存储，DOUBLE是近似值，把精确值放进近似字段，等于白折腾。小数位数要跟业务精度对齐：只有两位的场景用DECIMAL(19,2)，有汇率、利率的场景用DECIMAL(19,6)甚至更高。字段长度不够时，MySQL 默认会做四舍五入并给一个 warning，很多 ORM 框架不会把 warning 抛出来，数据就这么被悄悄改了。
ORM 映射层面，要确认实体类字段类型是BigDecimal而不是Double。有些老项目的实体类是自动生成的，生成器把decimal映射成了Double，读出来就已经带误差了，后面再怎么小心都没用。这个要专门检查一遍，尤其是接手遗留系统的时候。
序列化层面，JSON 序列化有几个坑。Jackson 默认把BigDecimal序列化成数字，1.50会输出成1.50，看起来没问题；但反序列化时如果 JSON 里是1.5，得到的BigDecimalscale 就是 1，跟数据库里的1.50不是equals关系。解决办法是配置DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS，并且在业务入口统一setScale。
另一个选择是金额以字符串序列化，前端拿到"1.50"而不是1.50，彻底避开 JavaScript 的浮点数精度问题。JS 的Number是双精度浮点，超过2^53的整数会丢精度，虽然一般金额到不了这个量级，但长 ID 类的字段经常出问题，统一用字符串传输是更稳的做法。代价是前端要做类型转换，需要在接口文档里写清楚。
5.3 代码评审时的检查项
规则要落地，最终得靠评审。我整理了一份检查清单，每次涉及金额的 PR 都过一遍：
| 检查项 | 不合格示例 | 正确写法 |
|---|---|---|
| 构造是否用了 double | new BigDecimal(0.1) | new BigDecimal("0.1") |
| 运算结果是否接住 | sum.add(x); | sum = sum.add(x); |
| 除法是否指定精度 | a.divide(b) | a.divide(b, 2, RoundingMode.HALF_UP) |
| 比较是否用了 equals | a.equals(b) | a.compareTo(b) == 0 |
| 是否用了废弃的 int 舍入常量 | BigDecimal.ROUND_HALF_UP | RoundingMode.HALF_UP |
| 入集合前是否统一 scale | 直接set.add(amount) | 先setScale再入集合 |
| 展示是否用了 toString | amount.toString() | amount.toPlainString() |
| 数据库字段是否为浮点类型 | double amount | DECIMAL(19,2) |
这张表贴在团队文档里比讲一百遍原理都管用，新人照着对一遍就能避开八成问题。
注意：工具类不是万能药。我见过团队把所有金额运算都塞进工具类，结果工具类里出现了
addWithTax、subtractWithDiscount这种业务方法，最后变成一坨谁也不敢改的泥球。工具类只该管“怎么算不出错”，不该管“算什么”，业务规则留在业务层，这条边界要守住。
6. 排查实录：那些报错信息到底在说什么
6.1 典型异常与原因对照表
BigDecimal相关的报错信息大多很直白，但第一次见容易懵。下面这些是我在实际项目里收集到的，按出现频率排序：
| 异常信息 | 触发原因 | 处理方式 |
|---|---|---|
Non-terminating decimal expansion; no exact representable decimal result | divide遇到无限循环小数且未指定精度 | 改用三参数divide |
Rounding necessary | 单参数setScale会丢精度 | 改用双参数版本指定舍入模式 |
Character array is missing "e" notation exponent | 字符串里有多余字符或格式错误 | 构造前清洗输入 |
Character , is neither a decimal digit number... | 字符串含千分位逗号 | 去掉逗号再构造 |
Overflow | longValueExact/intValueExact超出范围 | 检查数值量级，或改用BigDecimal存储 |
Division by zero | 除数为零 | 调用前判断signum() == 0 |
NullPointerException | compareTo、add等方法传了null | 调用前判空或用工具类兜底 |
“Rounding necessary” 这个异常名起得很有误导性，它不是说“必须舍入”，而是说“这次操作需要舍入但你没告诉我怎么舍”。改法就是补上RoundingMode，一句话的事。
6.2 排查路径：从日志到最小复现
遇到金额对不上，我的排查顺序是这样的，基本能在半小时内定位。
第一步，确认数据源。看数据库里存的是什么、接口返回的是什么、日志打出来的是什么，三者是否一致。很多时候问题出在某一层的转换上，而不是计算逻辑本身。特别要看有没有Double类型的中间变量，这是最常见的污染源。
第二步，看 scale。把可疑对象的scale()和precision()打出来，1.5和1.50在日志里长得一样，但scale不同。我习惯在日志模板里加一句value={}, scale={}，排查时能省很多时间。
第三步，写最小复现。把涉及的数值和运算顺序抽出来，写一个main方法跑一遍，看结果在哪一步开始偏离预期。这一步的关键是用原始输入复现，不要用近似值，因为问题往往就藏在某个特定的数值组合里。
第四步，检查舍入链路。如果中间有多次setScale，逐个打日志确认每次的结果。多次舍入会累积误差，2.4445先setScale(3, HALF_UP)变2.445，再setScale(2, HALF_UP)变2.45；而直接setScale(2, HALF_UP)得到的是2.44。这个差别在对账时能要人命。
6.3 我个人的几条硬规矩
最后分享几条我这些年固化下来的规矩，都是踩过坑之后加的，不一定每条都适合你，但至少值得想一想。
金额一律用字符串构造，从源头切断浮点污染。不管是数据库、配置、还是第三方接口，只要来源是数值，先转成字符串再进BigDecimal。多一次转换，少一类事故。
中间计算保留六位，最终结果保留两位。这个规则是为了避免多次舍入的累积误差。六位够覆盖绝大多数汇率和费率场景，最终统一舍到两位，舍入点只有一个，可控。
比较永远用compareTo，集合 key 永远先统一 scale。这两条是硬性的，没有例外。
除法必须显式指定精度和舍入模式，写在规范里，评审时看到没指定的直接打回。
涉及钱的地方不写“聪明”代码。什么a.add(b).multiply(c).divide(d, 4, HALF_UP).setScale(2, HALF_UP)这种一行链式调用，看着简洁，出了问题根本不知道是哪一步偏的。拆成几行，每行一个中间变量，日志能打，断点能停，维护成本低得多。
我在实际使用中的一个体会是，BigDecimal这个类本身的 API 设计其实是合理的，坑大多来自使用者的惯性——习惯了double的随手写、习惯了equals的通用语义、习惯了运算符的直觉。把这几个惯性改掉，剩下的就是记住几个方法名的事。真正难的不是学会它，是在团队里把正确的用法变成所有人的默认动作，这需要工具类、规范、评审三样东西一起上，光靠文档和口头提醒是不够的。
