BigDecimal实战：彻底解决double精度问题，掌握金额计算基本功

“如何用好BigDecimal”——这个问题我在面试中问过无数人，也在代码评审里看到过无数种错误用法。很多人用BigDecimal是为了解决double的精度问题，但真正用对的人并不多。有人拿new BigDecimal(0.1)构造出了0.1000000000000000055511151231257827021181583404541015625，有人用equals比较两个数值相同的BigDecimal得到false，还有人在除法里不指定精度直接抛ArithmeticException。这篇文章将我这些年用BigDecimal的完整经验梳理一遍，覆盖构造、运算、比较、格式化、性能、工具类封装等全部关键点，希望能帮你在项目里真正把这门“金额计算的基本功”练扎实。

1. 为什么非用BigDecimal不可：精度问题的根源

1.1 二进制浮点数的“天生缺陷”

要理解BigDecimal存在的意义，先得搞清楚double为什么会出问题。计算机底层存储浮点数时，用的是IEEE 754标准下的二进制科学计数法，也就是说，一个十进制小数要被转换成“二的负幂次方组合”来近似表示。

举个最经典的例子：0.1在二进制下是一个无限循环小数。就像十进制里1/3写不成有限小数一样，二进制里0.1、0.2这类十进制小数也没法精确表示。于是，double保存的0.1其实是一个最接近0.1的二进制浮点数，误差已经存在了。

System.out.println(0.1 + 0.2); // 输出0.30000000000000004

很多刚入行的开发第一次看到这个结果都会懵。实际上你在Java里执行0.1 + 0.2，底层做的是两个近似值的加法，结果自然不可能精确等于0.3。浮点数的相对误差虽然很小，但在累积运算、金额比较、百分比计算等场景下，误差会一步一步放大，最终导致线上事故。

1.2 double运算是怎么埋雷的

误差不是只在加法里出现。我在实际项目中见过的问题类型大致有三类：

第一类是自增累计误差。比如有一个订单系统，每天要累计上百笔金额来计算对账总额，如果用double每次累加，刚开始误差很小，但累计几百笔之后就可能出现几分钱的差异。对账系统一旦发现差一分钱，就要花大量时间去排查，非常痛苦。

第二类是乘除放大误差。典型场景是计算税率、折扣、汇率。0.1乘以0.2在double里算出0.020000000000000004，对金额业务来说，这个尾数一旦参与后续全部运算，结果就会产生连锁漂移。

第三类是直接比较出错。比如两个计算结果理论上都是50.0，但一个是通过50.0除以某个数再乘回来得到的，另一个是直接赋值50.0，用 == 比较就可能返回false。这在金额接近阈值的判断场景中非常致命。

1.3 BigDecimal的底层原理

BigDecimal之所以能精确表示十进制小数，是因为它不采用二进制浮点表示法，而是用一个大整数（BigInteger unscaledVal）配合一个描述小数位数的整数（scale）来存储数值。

以BigDecimal("123.45")为例，内部存储的就是：

• unscaledVal（未缩放值） = 12345。这里用BigInteger存储，避免普通long的位数上限。
• scale（小数位数） = 2，代表小数点向左移两位。

需要时，BigDecimal会把unscaledVal除以10的scale次方来得到实际数值。由于每一步运算都在整数域内完成，不会直接做二进制浮点近似，所以可以实现任意精度的十进制运算。这就是BigDecimal所有精确性的根本来源。

理解这个原理非常重要。你会明白BigDecimal的性能天然比double差很多，因为它要做大整数运算；你也就会明白scale（小数位）在加减乘除里有多重要。后面绝大部分“坑”都和scale有关。

2. 正确构造BigDecimal：三个方法背后的坑

2.1 千万不要用new BigDecimal(double)

很多新人会这样写：

BigDecimal bd = new BigDecimal(0.1); System.out.println(bd); // 输出0.1000000000000000055511151231257827021181583404541015625

看到这个结果你一定傻眼：我明明传的是0.1，为什么得到的不是0.1？

原因在于，new BigDecimal(double)拿到的是double在内存中的精确二进制表示。这个构造方法会“忠实”地把那个已经被二进制近似过的值原样转成BigDecimal，所以它接收到的是0.1的近似值，而不是人类眼中的0.1。

这个方法的设计初衷是让开发者能够准确地还原double的原始值——但绝大多数业务场景根本不需要这种“精确”，你需要的是把0.1当成0.1来处理。因此，除非你明确知道自己要还原某个double的二进制内容，否则永远不要使用这个构造方法。

2.2 推荐使用new BigDecimal(String)

最安全的做法是用字符串构造：

BigDecimal a = new BigDecimal("0.1"); BigDecimal b = new BigDecimal("0.3");

BigDecimal会按十进制逐位解析字符串，得到精确的数值。这句String构造相当于是“人类十进制的直接映射”，不会经过任何二进制转换，所以不存在精度损失。

我个人的习惯是：凡是金额从外部接口、数据库、配置中心或前端传入时，一律用字符串构造。如果前面代码传进来的是double，那就在源头先转成字符串，或者用valueOf方法，坚决不直接new BigDecimal(double)。

2.3 BigDecimal.valueOf的底层逻辑

BigDecimal.valueOf(0.1); // 等于 new BigDecimal("0.1")

valueOf做的事情就是调用Double.toString(double)先得到双精度值的十进制字符串表示，然后再走字符串构造。由于Double.toString在转换时会输出能恢复这个double的最短十进制形式，所以valueOf(0.1)得到的是精确的0.1，而不是0.1000...0055。

BigDecimal bd = BigDecimal.valueOf(0.1); System.out.println(bd); // 输出0.1

这个方法非常适合从double类型的数据源转换BigDecimal，比如从旧系统读取的double金额、历史数据中的double字段等场景。注意，valueOf还有一些内部缓存优化，对常用的0~10整数会复用同一个对象，但本质上它仍然是走字符串解析的。

2.4 其他构造方式与使用时机

• new BigDecimal(BigInteger)：把大整数转成BigDecimal，适合本身就是BigInteger的场景。
• new BigDecimal(char[])：把字符数组作为数值字符串处理，字符串很长时可以用这个避免创建String对象，但实际使用频率很低。
• BigDecimal.ZERO、BigDecimal.ONE、BigDecimal.TEN：这三个是预定义的常量，能用就用，省一个对象。JDK 9之后还有BigDecimal.ZERO等常量，不过日常最常用的还是ZERO、ONE、TEN。

还有一个日常容易踩的坑：把int、long直接new BigDecimal(1)其实是安全的，因为整数在二进制中可以精确表示。真正有问题的是小数。所以new BigDecimal(100)、new BigDecimal(100L)没问题，但new BigDecimal(0.1)就有问题。

2.5 构造方法选择速查表

场景	推荐方式	原因
字符串来源（JSON、接口、配置）	new BigDecimal("0.1")	精确解析，无中间转换
double来源（历史数据、外部系统）	BigDecimal.valueOf(0.1)	先转字符串，避免二进制近似
int/long来源（数量、整数金额）	BigDecimal.valueOf(n) 或 new BigDecimal(n)	整数天然精确
已知常量	BigDecimal.ZERO/ONE/TEN	复用常量对象，性能最好
被禁止的方式	new BigDecimal(0.1)	会保留double的二进制近似值

3. 运算规则与精度控制：scale、RoundingMode、MathContext

3.1 scale到底是什么

先说定义：scale表示小数点右边的位数。BigDecimal("123.45").scale()返回2，BigDecimal("0.001").scale()返回3，BigDecimal("100").scale()返回0。

scale在运算中的行为非常关键，因为加减乘除对scale的处理规则各不相同。如果你不求甚解，结果很可能被舍入得莫名其妙。举个例子：

BigDecimal a = new BigDecimal("1.50"); System.out.println(a.scale()); // 2 System.out.println(a); // 1.50

注意，1.50在BigDecimal里是两个精度的持有者：它不仅保存数值，还保存“1.50”这个带了两位小数的语义。这在金额场景中其实很重要，因为两位小数往往代表“元”层面的精确分。

3.2 加减法：取最大scale

BigDecimal a = new BigDecimal("1.20"); BigDecimal b = new BigDecimal("0.5"); System.out.println(a.add(b)); // 1.70 System.out.println(a.add(b).scale()); // 2

加法中，结果的scale一般是两个操作数中较大的那个scale。1.20的scale是2，0.5的scale是1，所以结果是scale为2的1.70。这个行为很好理解：结果要能容纳两个输入的全部小数位。

减法也一样。实际业务中，如果两个金额小数位数不同，相加后的结果会自动对齐到更多位的小数。这个默认行为通常符合直觉，不需要额外干预。

3.3 乘法：scale相加

BigDecimal a = new BigDecimal("1.20"); BigDecimal b = new BigDecimal("0.10"); System.out.println(a.multiply(b)); // 0.1200 System.out.println(a.multiply(b).scale()); // 4

乘法结果的scale是两者scale之和。1.20（scale 2）乘以0.10（scale 2），结果是0.1200（scale 4）。表面上数值是对的，但多出来的两个尾随零在后续输出或比较时可能会引发问题。因此，很多公司会要求乘法后显式调用setScale来标准化到业务要求的精度，比如统一保留两位小数。

3.4 除法：最常见的ArithmeticException来源

除法是BigDecimal里最麻烦的操作。如果除不尽，而你又没有指定舍入模式，Java会直接抛出ArithmeticException:

BigDecimal a = new BigDecimal("1"); BigDecimal b = new BigDecimal("3"); System.out.println(a.divide(b)); // 抛出ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

很多人第一次遇到会很懵：为什么1除以3会报错？因为1除以3在十进制下是无限循环小数0.3333...，BigDecimal想要精确表示这个无限小数，但它没有无限存储空间，所以需要你告诉它“保留几位，怎么舍入”。一旦你没给这两个信息，它只能报错。

解决方式是使用重载版本：

BigDecimal result = a.divide(b, 4, RoundingMode.HALF_UP); // 结果0.3333

因为除法太容易踩坑，我建议团队内统一约定：所有除法调用必须显式指定scale和RoundingMode。用divide方法时，要么传“精度+舍入模式”，要么传MathContext，禁止调用单参数的divide。

3.5 RoundingMode八个模式逐个拆解

舍入模式决定了“多余的小数位如何处理”，不同业务场景对舍入策略的诉求完全不同，选择错了就可能多一分钱或少一分钱。

• RoundingMode.UP：远离零方向舍入。不管正负，只要有多余位，就向绝对值增大的方向进一位。1.1保留整数得2，-1.1也得-2。
• RoundingMode.DOWN：趋向零方向舍入。直接截断多余位，不向上进位。1.9保留整数得1，-1.9得-1。
• RoundingMode.CEILING：向正无穷方向舍入。正数时等同于UP，负数时等同于DOWN。常用于一些计费系统的上限控制。
• RoundingMode.FLOOR：向负无穷方向舍入。正数时等同于DOWN，负数时等同于UP。
• RoundingMode.HALF_UP：四舍五入。0.5进位，这个最常见，金额计费、优惠计算基本都用它。
• RoundingMode.HALF_DOWN：五舍六入。0.5不进位，只有超过0.5才进位。比如2.5保留整数得2，2.6得3。用得较少。
• RoundingMode.HALF_EVEN：银行家舍入。0.5时看前一位，奇数进位，偶数舍弃。比如2.5保留整数得2，3.5得4。这个方法在金融统计中有应用，因为它能让大量数据的舍入误差尽可能均匀分布。如果你的业务对“统计无偏”有要求，它比四舍五入更科学。
• RoundingMode.UNNECESSARY：断言运算结果不需要舍入，如果出现多余位，直接抛ArithmeticException。这个模式很少用于线上，主要用于测试，验证你的计算是否真的“除得尽”。

3.6 MathContext的使用注意事项

MathContext是“精度+舍入模式”的组合体，它有两个核心属性：precision（有效数字位数，不是小数位）和roundingMode。

MathContext mc = new MathContext(4, RoundingMode.HALF_UP); BigDecimal a = new BigDecimal("123.456"); System.out.println(a.round(mc)); // 123.5，因为有效数字是4位

注意precision控制的是“从最高非零数字开始的总有效位数”，和setScale控制的小数位数完全不是一回事。很多新手在这里混淆，导致结果和自己预期完全不符。

在运算时你还可以直接这样使用：

BigDecimal result = a.divide(b, mc);

此时精度限制会影响整个运算过程。但在日常金额计算里，我更建议显式指定scale而不是用MathContext，因为在金额场景下，“保留两位小数”的表述比“保留4位有效数字”更明确、更好维护。

3.7 setScale：你真正的“精度设置入口”

setScale(int newScale, RoundingMode roundingMode)可以把一个BigDecimal的小数位调整到指定精度，这是金额计算中最常用到的方法。

BigDecimal amount = new BigDecimal("123.456"); BigDecimal rounded = amount.setScale(2, RoundingMode.HALF_UP); System.out.println(rounded); // 123.46

如果新scale比原来大，比如把123.45变成123.450，setScale会做“补零”，这不会改变数值大小，但会修改scale，影响toString输出和equals比较。所以这个操作并不是无副作用的，需要结合业务语义来判断是否要做。

另一个需要注意的重载：setScale(int newScale)（不传舍入模式）在需要舍入时会抛ArithmeticException，只有纯粹“缩小或扩大scale但不需要舍入”时才允许调用。所以我极少用单参数的setScale，统一用两个参数的版本更稳。

4. 比较与相等：equals和compareTo的恩怨

4.1 equals比较的是数值和scale双重相等

这是BigDecimal最常见的坑之一。看看下面这段代码：

BigDecimal a = new BigDecimal("1.0"); BigDecimal b = new BigDecimal("1.00"); System.out.println(a.equals(b)); // false

在业务直觉里，1.0和1.00当然是同一个数，但BigDecimal的equals认为它们是不同的对象，因为数值相同而精度（scale）不同。底层实现中，equals会先比较scale，再比较unscaledVal，两个条件都满足才返回true。

这个特性直接导致一个常见错误：在金额比较、Map去重、Set去重时，把两个“看起来一样”的金额判断为不同。如果你的业务确实要求“数值相等即可”，就不能依赖equals。

4.2 compareTo才是真正比较数值大小的方法

compareTo会忽略scale，只比较数值本身：

BigDecimal a = new BigDecimal("1.0"); BigDecimal b = new BigDecimal("1.00"); System.out.println(a.compareTo(b) == 0); // true

在编写金额判断逻辑时，请一律使用compareTo：

if (amount.compareTo(BigDecimal.ZERO) > 0) { // 正数 }

4.3 排序和去重时的注意点

使用TreeSet或TreeMap时，如果元素是BigDecimal，默认排序用的就是compareTo逻辑，所以TreeSet中1.0和1.00会被当作相等元素去重。这其实符合大多业务预期。

但如果你用的是HashMap或HashSet，它们的hashCode计算是基于equals的，因此1.0和1.00会hash到不同槽位，作为两个不同的key存在。这可能会在金额汇总时漏算，或者在做金额维度统计时出现逻辑脏数据。

我的建议是，在金额对象中尽量统一scale，比如所有金额都在入库前setScale(2, RoundingMode.HALF_UP)。这样equals和compareTo的结果就一致了，后续无论用什么集合结构都不会出问题。

4.4 金额为0的判断

判断是否为零也有讲究。BigDecimal.ZERO.compareTo(value) == 0是标准做法，不要用value.equals(BigDecimal.ZERO)，因为value可能是0.00、0.000这样的形式，equals会返回false。

BigDecimal value = new BigDecimal("0.00"); System.out.println(value.equals(BigDecimal.ZERO)); // false System.out.println(value.compareTo(BigDecimal.ZERO) == 0); // true

5. 格式化与转换：每个输出场景都有一堆坑

5.1 toString与toPlainString的区别

BigDecimal重写了toString，但输出方式有时会让业务方困惑。比如：

BigDecimal a = new BigDecimal("0.000001"); System.out.println(a.toString()); // 1E-6 System.out.println(a.toPlainString()); // 0.000001

当数值绝对值很小或很大时，toString可能输出科学计数法形式（如1E-6），而toPlainString始终输出普通十进制写法。如果你在做文件导出、账单调取、接口返回，建议统一使用toPlainString，避免产生“E-6”这种让业务人员摸不着头脑的字符串。

5.2 stripTrailingZeros：一个必须小心的标准化方法

BigDecimal a = new BigDecimal("1.500"); System.out.println(a.stripTrailingZeros()); // 1.5

stripTrailingZeros会移除所有尾随零，但有个特殊行为：数值为0时，结果可能变成scale为负数的情况，而且toString输出可能是0E-？的形式。比如：

BigDecimal zero = new BigDecimal("0.00"); System.out.println(zero.stripTrailingZeros()); // 0.00，在JDK 8下输出0.00，JDK 9后可能输出0 System.out.println(zero.stripTrailingZeros().toPlainString()); // 部分JDK版本输出0

不同JDK版本的输出存在差异，所以如果你要输出标准化结果，不要只依赖stripTrailingZeros，应该结合toPlainString和setScale。

5.3 BigDecimal转double：精度可能再次丢失

BigDecimal a = new BigDecimal("0.123456789123456789"); double d = a.doubleValue(); // 0.12345678912345678

doubleValue会把BigDecimal转成double，精度再次被二进制浮点数限制。如果只是把结果给图表展示、给统计计算，可以接受；但如果要做金额入账、对账，绝对不能转double。同理，floatValue、intValue、longValue都会做精度截断，需要非常谨慎。

我这里有个血的教训：某次做报表导出时，金额字段先转成了double再传给Excel模板，结果Excel里看到的金额和数据库对不上。排查后发现是转double丢精度。从那以后我定了一个铁律：金额链路里，任何一步都不允许转double，除非最终只用于展示且对尾数无要求。

5.4 用DecimalFormat控制输出格式

展示金额时经常需要带千分位、保留两位小数。DecimalFormat可以直接格式化BigDecimal：

BigDecimal amount = new BigDecimal("1234567.891"); DecimalFormat df = new DecimalFormat("#,##0.00"); System.out.println(df.format(amount)); // 1,234,567.89

注意，DecimalFormat默认使用的舍入模式是RoundingMode.HALF_EVEN，不是HALF_UP。如果你希望四舍五入，需要显式设置：

df.setRoundingMode(RoundingMode.HALF_UP);

另外，格式模式里的0表示“必须显示的位”，#表示“有值才显示”。比如"#.##"对于1.5会输出1.5，"0.00"对于1.5会输出1.50。到底用哪种模式，取决于你的业务展示要求。

5.5 JSON序列化和反序列化的坑

Java的JSON序列化框架（如Jackson、Gson、Fastjson）对BigDecimal的默认支持通常把对象输出为数值。这里有个隐患：如果BigDecimal值是1.50，序列化为JSON时会输出1.50还是1.5，取决于序列化器的配置。

反序列化时，也容易出问题。如果JSON里金额字段写成{"amount": 1.50}，框架可能会先把它解析成Double，再构造BigDecimal，实际上很多框架采用的是字符串构造，但也有些框架会用new BigDecimal(number)，这时就会用到那个有隐患的double构造方法。

为了规避这个问题，我建议在JSON的金额字段上统一使用字符串类型接收，需要时再转BigDecimal；或者配置Jackson的DeserializationFeature，让解析过程使用BigDecimal而非Double。

5.6 与数据库交互时的注意事项

数据库映射BigDecimal时，最稳妥的方式是用DECIMAL类型。MySQL的DECIMAL(10,2)表示总共10位数字、其中2位小数，正好对应金额的“元+分”模型。JDBC在读取DECIMAL列时，一般会返回BigDecimal对象，并且scale与数据库定义一致。

如果你用ORM框架（MyBatis、Hibernate）操作这个字段，注意插入前最好把scale统一到数据库定义的小数位。如果你在Java代码里使用BigDecimal("10")（scale 0）去插入DECIMAL(10,2)列，一些数据库驱动会自动补齐，但为了保险起见，给入库字段显式setScale(2)更稳妥。

6. 实用技巧与性能注意事项

6.1 不可变性与对象复用

BigDecimal是不可变对象，每个运算方法返回的都是新对象，原对象不会被修改。这对线程安全是好事，但也会让每个运算都产生新对象，频繁操作时性能开销不容忽视。

在循环中创建BigDecimal对象、频繁做加法，会明显增加GC压力。如果对性能有要求，尽量复用常量，避免在循环体内new BigDecimal：

// 不推荐 for (int i = 0; i < 1000000; i++) { BigDecimal result = sum.add(new BigDecimal("0.01")); } // 更优做法：常量提到循环外 BigDecimal increment = new BigDecimal("0.01"); for (int i = 0; i < 1000000; i++) { result = result.add(increment); }

需要明确的是，即使做了这些优化，BigDecimal的性能也远低于double。如果你做的是百万级金额运算，性能可能会成为瓶颈。这种情况可以考虑用long表示“分”来运算，最后再转BigDecimal。但这是性能优化的兜底方案，日常业务里不建议轻易引入，因为可读性会下降。

6.2 金额计算工具类的设计原则

为了让团队少踩坑，我在项目里通常封装一个MoneyUtils工具类，把所有常见操作收敛到一个地方：

public final class MoneyUtils { private static final int SCALE = 2; public static BigDecimal of(String value) { return new BigDecimal(value); } public static BigDecimal of(double value) { return BigDecimal.valueOf(value); } public static BigDecimal add(BigDecimal a, BigDecimal b) { return nullSafe(a).add(nullSafe(b)); } public static BigDecimal subtract(BigDecimal a, BigDecimal b) { return nullSafe(a).subtract(nullSafe(b)); } public static BigDecimal multiply(BigDecimal a, BigDecimal b) { return nullSafe(a).multiply(nullSafe(b)).setScale(SCALE, RoundingMode.HALF_UP); } public static BigDecimal divide(BigDecimal a, BigDecimal b) { return nullSafe(a).divide(nullSafe(b), SCALE, RoundingMode.HALF_UP); } public static BigDecimal scale(BigDecimal a) { return nullSafe(a).setScale(SCALE, RoundingMode.HALF_UP); } public static boolean equalsValue(BigDecimal a, BigDecimal b) { return nullSafe(a).compareTo(nullSafe(b)) == 0; } private static BigDecimal nullSafe(BigDecimal a) { return a == null ? BigDecimal.ZERO : a; } }

注意几个设计细节：

• null统一按0处理，避免每处都要判空。
• 乘法、除法统一指定scale和舍入模式，不允许调用方自行传入，避免标准不一致。
• 比较用compareTo，不用equals。
• 所有方法接收BigDecimal，不接受double入参，从源头堵住新坑。

当然，工具类只能减少低级错误，真正的规范还得靠代码评审和团队约定来保障。

6.3 什么时候可以不用BigDecimal

BigDecimal不是万能的，更不是所有数值计算都要用它。

如果你做的是科学计算、数学模型、统计指标计算，double完全够用，甚至更合适，因为这些场景对相对误差的容忍度更高，但对计算速度的要求极高。

如果数字代表的是整数类型的数量（比如订单数、库存件数），优先用int、long，根本没有必要用BigDecimal。

BigDecimal真正的黄金应用区是金融、电商、支付、计费等与“钱”强相关的领域，凡是需要精确到分的数值，都应该用BigDecimal。

7. 实战复盘：一个金额计算核心服务的完整实现

7.1 需求场景

假设后台需要计算一个订单的总价。订单包含多件商品，每件商品有单价（BigDecimal）、数量（int）、折扣率（BigDecimal，例如0.85表示85折），还需要计算运费，最后得到应付金额，保留两位小数，四舍五入。

订单明细结构简化为：

class OrderItem { private String productName; private BigDecimal price; // 单价，两位小数 private int quantity; // 数量 private BigDecimal discount; // 折扣率，如0.85 }

7.2 实现过程

第一步，先把单项商品的原价算出来。注意这里如果数量用int，乘法时可以做BigDecimal.valueOf(quantity)转换：

BigDecimal itemAmount = item.getPrice() .multiply(BigDecimal.valueOf(item.getQuantity()));

这一步的输出scale是两个操作数scale之和。如果price是两位小数，quantity是整数，则结果还是两位小数。但如果price带有两位以上小数，结果就可能出现更多位小数。

所以我在相加前会统一用MoneyUtils.scale()做一次标准化：

BigDecimal discountedAmount = MoneyUtils.scale( itemAmount.multiply(item.getDiscount()) );

这里乘完折扣率之后，scale可能是五到六位，直接标准化到两位小数可以防止后续累计时出现多余精度。

第二步，汇总所有商品金额。

BigDecimal totalAmount = BigDecimal.ZERO; for (OrderItem item : items) { BigDecimal itemDiscounted = ...; // 上文计算 totalAmount = totalAmount.add(itemDiscounted); }

第三步，处理运费。运费本身是固定值，但有一个业务规则：实付满99元免运费，否则收6元运费。这里用到compareTo来判断：

BigDecimal shippingFee = totalAmount.compareTo(new BigDecimal("99")) >= 0 ? BigDecimal.ZERO : new BigDecimal("6.00");

第四步，返回最终应付金额。由于每一步add都已经标准化过，最后我还会再做一次兜底setScale：

BigDecimal payable = MoneyUtils.scale(totalAmount.add(shippingFee));

7.3 这段代码里的经验要点

• 所有输入数据都假设是从JSON或数据库获得的字符串，优先用字符串构造。
• 不要在循环中new BigDecimal，循环外尽量用常量。
• 每一步乘除后都立即标准化，不让多余精度在链路上累积。
• 金额大小的判断用compareTo，不用equals，也不转double。
• 最终输出统一调用scale()方法，保证入库时小数位数一致。

很多坑只有跑到线上才会暴露，比如某个渠道的优惠金额算出来多了0.01，某次促销导致全平台对账差了一分钱。这些往往不是算法复杂，而是在某个你看不到的乘法或除法里埋下了精度隐患。

8. 常见问题速查与避坑清单

8.1 高频问题速查表

问题	原因	解决方案
new BigDecimal(0.1)得到很多位小数	double构造保留了二进制近似值	改用new BigDecimal("0.1")或BigDecimal.valueOf(0.1)
equals比较1.0和1.00返回false	equals同时比较scale	用compareTo比较数值
除法抛ArithmeticException	除不尽但未指定精度与舍入模式	用divide(a, b, scale, RoundingMode.HALF_UP)
toString输出1E-6	小数值被输出为科学计数法	用toPlainString
doubleValue后金额变了	BigDecimal转double丢精度	金额链路中禁止转double
DecimalFormat结果不是四舍五入	DecimalFormat默认HALF_EVEN	显式调用setRoundingMode(HALF_UP)
HashMap中1.0和1.00是两个key	hashCode基于equals	统一scale，或用TreeMap

8.2 我踩过的一次真实事故

有一次接手一个电商平台的订单导出功能，导出的CSV文件金额总和总是和数据库对不上，差的金额是几角钱，但用户反馈很强烈。排查后发现，源头是在导出代码里有人写了这样一行：

double amount = order.getAmount().doubleValue();

然后再用DecimalFormat格式化输出。doubleValue把两位小数的BigDecimal转成了二进制浮点数，DecimalFormat再按默认模式输出，部分金额就产生了0.01~0.1的偏差。修复方法很简单：直接用order.getAmount()参与格式化，不转double。

这个事故之后我复盘出两点：第一，代码评审必须检查金额链路中是否有人用doubleValue、floatValue、intValue；第二，金额字段在代码里要形成“类型安全”的共识，任何计算入口和出口都只用BigDecimal。

8.3 方案选择层面的大坑

有些团队为了“省事”，会在金额计算中用double做中间计算，最后才转成BigDecimal。这是最危险的做法。因为double计算过程中的误差已经混入结果，后面再怎么转BigDecimal都无法消除，只会保留一个带着误差的近似结果。

比如： 0.1 + 0.2先算出0.30000000000000004，再转BigDecimal，得到的就是0.30000000000000004。

这种链条式的精度污染是最难排查的。正确做法是从第一笔加法开始全部用BigDecimal，中途不要出现任何double。宁可损失一点性能，也要保证账目准确。

8.4 给新手的三个练习

如果你刚接触BigDecimal，我建议先动手做三组练习：

第一组，打印new BigDecimal(0.1)、new BigDecimal("0.1")、BigDecimal.valueOf(0.1)的结果，观察它们的差异并思考原因。

第二组，依次计算1除以3的四种舍入模式结果，观察HALF_UP、HALF_DOWN、HALF_EVEN、UP的区别。

第三组，把一个两位小数金额与本身相加100万次，比较用BigDecimal和用double的最终结果差多少。

这三组练习做下来，基本就能理解BigDecimal的核心行为了，比看十篇博客都管用。

9. 写在最后：把精度意识变成肌肉记忆

我在带团队做代码评审时，对金额相关代码只有一个要求：每一步运算都问自己三个问题——这个数从哪里来，它是BigDecimal还是double，运算之后scale是否被有意控制。凡是答不上来第三条的，一律打回重写。听起来严格，但正是这种严格，让我们的对账系统能在两个月内做到零差错线，也让团队里每个开发都对“精度”这两个字保持敬畏。

最后分享一个我个人的小习惯：无论业务中实际需要几位小数，工具类的默认SCALE都建议收敛到2。如果哪天你遇到一个用4位小数或6位小数的需求，不要急着改常量，先想清楚这多出来的精度会在哪里被截断、会不会引发后续比较或展示问题。先把账户体系里的精度边界定清楚，等于提前给项目买了一份保险。