“如何用好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、MathContext3.1 scale到底是什么先说定义scale表示小数点右边的位数。BigDecimal(123.45).scale()返回2BigDecimal(0.001).scale()返回3BigDecimal(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 加减法取最大scaleBigDecimal 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是20.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.20scale 2乘以0.10scale 2结果是0.1200scale 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保留整数得22.6得3。用得较少。RoundingMode.HALF_EVEN银行家舍入。0.5时看前一位奇数进位偶数舍弃。比如2.5保留整数得23.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.450setScale会做“补零”这不会改变数值大小但会修改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在编写金额判断逻辑时请一律使用compareToif (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); // true5. 格式化与转换每个输出场景都有一堆坑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.5stripTrailingZeros会移除所有尾随零但有个特殊行为数值为0时结果可能变成scale为负数的情况而且toString输出可能是0E-的形式。比如BigDecimal zero new BigDecimal(0.00); System.out.println(zero.stripTrailingZeros()); // 0.00在JDK 8下输出0.00JDK 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.12345678912345678doubleValue会把BigDecimal转成double精度再次被二进制浮点数限制。如果只是把结果给图表展示、给统计计算可以接受但如果要做金额入账、对账绝对不能转double。同理floatValue、intValue、longValue都会做精度截断需要非常谨慎。我这里有个血的教训某次做报表导出时金额字段先转成了double再传给Excel模板结果Excel里看到的金额和数据库对不上。排查后发现是转double丢精度。从那以后我定了一个铁律金额链路里任何一步都不允许转double除非最终只用于展示且对尾数无要求。5.4 用DecimalFormat控制输出格式展示金额时经常需要带千分位、保留两位小数。DecimalFormat可以直接格式化BigDecimalBigDecimal 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.50.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 什么时候可以不用BigDecimalBigDecimal不是万能的更不是所有数值计算都要用它。如果你做的是科学计算、数学模型、统计指标计算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都已经标准化过最后我还会再做一次兜底setScaleBigDecimal 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返回falseequals同时比较scale用compareTo比较数值除法抛ArithmeticException除不尽但未指定精度与舍入模式用divide(a, b, scale, RoundingMode.HALF_UP)toString输出1E-6小数值被输出为科学计数法用toPlainStringdoubleValue后金额变了BigDecimal转double丢精度金额链路中禁止转doubleDecimalFormat结果不是四舍五入DecimalFormat默认HALF_EVEN显式调用setRoundingMode(HALF_UP)HashMap中1.0和1.00是两个keyhashCode基于equals统一scale或用TreeMap8.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位小数的需求不要急着改常量先想清楚这多出来的精度会在哪里被截断、会不会引发后续比较或展示问题。先把账户体系里的精度边界定清楚等于提前给项目买了一份保险。