在Java开发的江湖里流传着一条不成文的铁律：涉及到金额计算，必须上BigDecimal。这几乎是每个初级程序员在入行时被前辈敲打进脑子的常识。毕竟谁也不想因为那一分钱的误差，在月底对账时面对财务部小姐姐那杀人般的目光，对吧？

但是哪怕你老老实实地引入了BigDecimal，就真的万事大吉了吗？

现实往往比骨感geng残酷。hen多有着三五年经验的开发者在处理高精度数值时依然会掉进坑里。你有没有遇到过这种情况：明明用了BigDecimal，结果打印出来的数字还是一长串kan不懂的乱码，或者是在Zuo乘法除法时莫名其妙地少了几厘？这时候你可Neng会对着屏幕怀疑人生：“说好的精确计算呢？怎么连你也背叛了我？”

今天我们就来撕开这层技术面纱，深扒一下为什么BigDecimal也会出现精度丢失，以及如何彻底根治这个顽疾。

一、 不仅仅是BigDecimal：二进制世界的“原罪”

要搞清楚BigDecimal的问题，我们得先回头kankan它的“前任”——float和double。为什么大家dou要抛弃它们？

这其实不是Java的错，而是计算机世界的“原罪”。我们的计算机是基于二进制运转的，这hen完美，但也hen死板。在十进制世界里像0.1、0.2这种数字kan起来hen乖巧，但在二进制眼里它们简直就是一群“无限循环小数”的恶霸。

这就好比在十进制里我们无法精确表示1/3一样，你只Neng写成0.3333...后面无限加3。计算机在存储double或float时宽度是有限的。面对无限循环的二进制小数，计算机只Neng无奈地Zuo一个动作：“截断”。

这种截断，就是精度丢失的万恶之源。

不信？你跑一下这段代码，绝对Neng颠覆你的认知：

public class FloatTest {
    public static void main {
        System.out.println; // 你以为是0.3？天真！输出是0.30000000000000004
        System.out.println; // 输出0.09999999999999998
        System.out.println; // 输出10.499999999999998
    }
}

kan到了吧？这就是为什么在金融、电商、计量这些领域，double和double是绝对不Neng上桌的。它们不仅算不准，而且误差会随着运算次数的增加像滚雪球一样越滚越大。

二、 BigDecimal的“背叛”：构造函数的陷阱

既然double不靠谱，我们请出了BigDecimal。它是专门为了解决这种问题而生的“大杀器”，内部使用的是十进制来存储数据，理论上Ke以完美避开二进制的坑。

但是！请注意这个但是！

hen多新手，甚至一些老手，在创建BigDecimal对象时习惯性地这样写：

BigDecimal price = new BigDecimal;

这就完蛋了。这简直是“才出虎穴，又入狼窝”。

为什么？因为当你把一个`double`类型的值传给BigDecimal的构造函数时BigDecimal接收到的并不是你心目中那个完美的“0.1”，而是double在内存中那个Yi经被“截断”了的、带有误差的二进制值。BigDecimal只是忠实地把这个“脏数据”转换成了自己的格式而Yi。

这就好比你用一张模糊的照片去打印高清海报，打印技术再好，出来的照片依然是模糊的。

我们来kankan对比：

// 错误示范：直接用double构造，把double的误差原封不动地继承了下来
BigDecimal wrong = new BigDecimal;
System.out.println; // 输出：0.1000000000000000055511151231257827021181583404541015625
// 正确示范1：用String构造，告诉计算机“我要的就是0.1，多一个标点符号dou不要”
BigDecimal right1 = new BigDecimal;
System.out.println; // 输出：0.1
// 正确示范2：使用BigDecimal.valueOf，这个方法底层帮我们把double转成了String
BigDecimal right2 = BigDecimal.valueOf;
System.out.println; // 输出：0.1

所以结论非常明确在构造BigDecimal时绝对、绝对、绝对不要使用`new BigDecimal`！这是导致精度丢失的头号杀手。请务必养成使用`String`构造或者`BigDecimal.valueOf`的习惯。

三、 运算时的“暗礁”：除不尽的尴尬

好了现在我们学会了如何正确地“生”出一个BigDecimal。接下来是“算”。

BigDecimal是个对象，不是基本数据类型，你不Neng直接用`+`、`-`、`*`、`/`这些符号来折腾它。你得老老实实调用它的方法：`add`, `subtract`, `multiply`, `divide`。

加减乘还好说一般不会出大乱子。但除法，这里埋着一颗巨大的地雷。

试想一下用BigDecimal计算“1除以3”。在十进制里这是0.3333...无限循环。BigDecimal虽然精度高，但它的内存也是有限的，它不可Neng存下无限位的小数。Ru果你不告诉它“该停在哪里”，它就会崩溃，直接给你抛出一个`ArithmeticException`，告诉你：“哥们，这数除不尽啊，我咋办？”

这就是hen多新手在跑代码时突然报错的原因。

怎么破？你得给它立规矩。告诉它：保留多少位小数，多出来的部分怎么处理。

public class BigDecimalCalc {
    public static void main {
        BigDecimal a = new BigDecimal;
        BigDecimal b = new BigDecimal;
        // 这样写会报错：Non-terminating decimal expansion; no exact representable decimal result.
        // BigDecimal result = a.divide;
        // 正确写法：指定保留2位小数，使用四舍五入
        BigDecimal result = a.divide;
        System.out.println; // 输出3.33
    }
}

这里有个细节要注意，乘法虽然通常不会抛异常，但Ru果不加控制，小数位数可Neng会无限膨胀。比如两个4位小数相乘，结果可Neng是8位小数。在金额计算里这通常是不允许的。所以Zuo乘法时Zui好也顺手`setScale`一下把多余的尾巴砍掉。

舍入模式怎么选？别再只懂“四舍五入”了

说到舍入模式，hen多人只知道`ROUND_HALF_UP`。但在复杂的业务场景里这远远不够。这里简单列举几个常用的：

ROUND_HALF_UP也就是我们小学学的四舍五入。>=5进位。这是Zui常用的，一般金额计算dou用它。

ROUND_DOWN直接截断，不要任何进位。比如2.59保留一位小数变成2.5。这通常用于计算“Zui小支付金额”或者某些优惠计算，商家不想多给一分钱时。

ROUND_UP只要有多余的位数，不管多少，dou进位。比如2.51保留一位变成2.6。这常用于计算税费或手续费，确保一分钱dou不Neng少。

四、 全链路防护：别让JSON和数据库毁了你的努力

你以为在Java代码里写对了就安全了？Too young, too simple。

你的数据是要流动的。它要去数据库，要变成JSON传给前端。在这个过程中，精度丢失的幽灵依然在游荡。

1. 数据库交互

在数据库设计表结构时金额字段千万不要用`FLOAT`或`DOUBLE`。请务必使用`DECIMAL`或`NUMERIC`类型。

比如：

amount DECIMAL  -- 19位有效数字，其中2位是小数

在MyBatis映射时Java实体类里直接用`java.math.BigDecimal`接收。千万别自作聪明地用`Double`去接，这一接，之前的努力全白费了。

2. JSON序列化

当你使用Fastjson或Gson把对象转成JSON字符串返回给前端时Ru果不小心配置，框架可Neng会把BigDecimal当成Double处理，导致精度丢失。

特别是Fastjson，早期版本默认可Neng会把BigDecimal转成double输出。比如你存的是12.0700，转完JSON变成12.7，前端拿到一脸懵逼。

解决办法hen简单，在序列化时开启特定的配置，或者直接告诉它：这是BigDecimal，给我按字符串发出去！

// 使用Fastjson的SerializerFeature配置
String jsonString = JSON.toJSONString(obj,
    SerializerFeature.WriteBigDecimalAsPlain); // 这样就Neng保证原样输出

五、 终极解决方案：封装一个“无脑”工具类

说了这么多，道理dou懂，但一写代码又忘怎么办？毕竟人总是容易犯错的。

Zui好的办法就是：不要让业务开发人员直接操作BigDecimal的细节。

结合多年的项目填坑经验，我建议在项目中封装一个专门的金额计算工具类，比如叫`MoneyUtil`。把那些繁琐的构造、setScale、舍入模式全部封装在底层。业务开发只需要调用`add`、`sub`、`mul`、`div`，完全不用关心底层是怎么转的。

这里给个简易的模板，大家Ke以拿去直接用，或者根据自己公司的业务规范改一改：

import java.math.BigDecimal;
public class MoneyUtil {
    // 定义全局的精度和舍入模式，避免到处硬编码
    // 金额通常保留2位小数
    private static final int SCALE = 2;
    // 四舍五入
    private static final int ROUND_MODE = BigDecimal.ROUND_HALF_UP;
    private MoneyUtil {}
    // 加法
    public static BigDecimal add {
        if  a = BigDecimal.ZERO;
        if  b = BigDecimal.ZERO;
        return a.add.setScale;
    }
    // 减法
    public static BigDecimal subtract {
        if  a = BigDecimal.ZERO;
        if  b = BigDecimal.ZERO;
        return a.subtract.setScale;
    }
    // 乘法
    public static BigDecimal multiply {
        if  return BigDecimal.ZERO;
        return a.multiply.setScale;
    }
    // 除法
    public static BigDecimal divide {
        if  a = BigDecimal.ZERO;
        if  == 0) {
            throw new IllegalArgumentException;
        }
        return a.divide;
    }
}

有了这个类，你在业务代码里就Ke以写得hen优雅：

BigDecimal total = MoneyUtil.multiply;
BigDecimal discount = MoneyUtil.subtract;

不用管`new BigDecimal`还是`valueOf`，也不用管会不会抛异常，工具类dou帮你兜底了。这才是工程化的正确打开方式。

技术这东西，往往细节决定成败。BigDecimal虽然强大，但也像是一匹烈马，Ru果你不懂它的脾性，不仅跑不快，还容易把你甩下来。

一下今天的核心心法：

拒绝double永远不要用`new BigDecimal`，请拥抱String。

规矩运算除法必须指定精度和舍入模式，乘法建议手动截断。

全链路统一数据库用DECIMAL，Java用BigDecimal，JSON配置好序列化策略。

封装工具别让每个开发者dou去重复造轮子，统一封装，统一规范。

只要Zuo到这几点，不管是几毛几分的账，还是上亿的资金流，douNeng算得清清楚楚，明明白白。毕竟在代码的世界里精准才是Zui大的优雅。

---