Java BigDecimal 为什么用 double 构造会产生尾数误差

new BigDecimal(double) 会精确保存传入 double 实际代表的数值。许多十进制小数无法用有限二进制位精确表示，误差在变成 double 时已经出现；构造器只是把这个近似值完整地表达成十进制。原始输入是十进制文本时，应直接用字符串构造；已有 double 时通常选 BigDecimal.valueOf(double)，但它不能恢复此前丢失的信息。

官方 API 地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/math/BigDecimal.html。最小写法如下，代码片段可放入合适的方法体，本文未编译或运行：

import java.math.BigDecimal;

// 十进制文本直接进入 BigDecimal，不先经过 double
BigDecimal length = new BigDecimal("12.35");
BigDecimal count = BigDecimal.valueOf(4L);
BigDecimal total = length.multiply(count);

批量处理时先统一数值入口

假设一项包装明细处理任务会接收很多条十进制长度，再乘以件数生成累计长度。单条显示只保留两位小数时，尾部差异可能不显眼；同类记录经过不同导入入口、转换和计算路径后，比较或汇总却可能出现不一致。

这里的改造重点是统一输入与计算模型。文本、整数和已有浮点值应明确区分；不能仅在最终输出时换成 BigDecimal，就认为整条链路已经采用了十进制运算。本文不提供吞吐量、性能改善或真实上线数据。

原来的误差发生在 double 转换处

double 使用二进制浮点表示。一些值可以精确表示，例如 0.5；另一些十进制分数则只能选取相近的有限浮点值。控制台给出的简短显示，并不等于那个 double 内部就保存了同样位数的十进制数。

BigDecimal 的 double 构造器对这个实际数值做精确转换。因此看到长尾数字时，不应把它理解成 BigDecimal 随机增加了小数位，也不应据此推断所有 double 都会产生同样现象。

import java.math.BigDecimal;

// 用数值比较展示两种输入语义；这是解释性示例，未执行
double source = 12.35;
BigDecimal binaryValue = new BigDecimal(source);
BigDecimal decimalText = new BigDecimal("12.35");

// 关注数值差异，避免 equals 把 scale 差异也算进来
int comparison = binaryValue.compareTo(decimalText);
BigDecimal difference = binaryValue.subtract(decimalText);

按 API 语义，示例中的 comparison 不为 0，difference 也不是数值零。这里只给出推导结论，不把某段控制台文字冒充执行结果。若改用能精确表示的二进制分数，情况就可能不同。

诊断时应寻找最早一次从文本或十进制数据进入 double 的位置。只盯着最后一行构造代码，可能忽略了上游反序列化、计算或中间字段已经发生的近似。

把十进制输入留在十进制模型中

如果接口或文件给出的就是十进制文本，可以让文本直接进入字符串构造器。后续使用 add、multiply 等 BigDecimal 方法完成运算，避免先调用 doubleValue 计算再转回来。

BigDecimal 由未缩放整数与 scale 表达十进制数值。文本中的 12.35 可以直接形成对应的十进制表示；如果输入还要约束最多两位小数，可以在入口采用下面的示例策略。

import java.math.BigDecimal;
import java.math.RoundingMode;

// 示例契约：最多两位小数，超出时拒绝，不静默舍入
static BigDecimal parseLength(String raw) {
    try {
        return new BigDecimal(raw).setScale(2, RoundingMode.UNNECESSARY);
    } catch (NumberFormatException | ArithmeticException error) {
        throw new IllegalArgumentException("长度必须是可精确表示为两位小数的数值", error);
    }
}

这是一段类内方法示例，调用方需要先保证 raw 非 null，并按接口契约限制文本长度。UNNECESSARY 表示如果缩放需要丢弃非零小数位就报错；它并不禁止末尾多余的零，例如 12.350 仍可精确缩放为两位。若业务接受舍入，应明确改为所需 RoundingMode，而不是套用一个没有业务依据的默认规则。

已有 double 时选择 valueOf 的边界

如果上游只提供 double，valueOf 使用 Double.toString 给出的规范字符串表示来建立 BigDecimal。这与直接展开 double 的精确二进制数值不同，通常更符合开发者对短小十进制表示的预期。

import java.math.BigDecimal;

// 对已有 double 采用规范字符串表示，不能恢复之前丢失的信息
BigDecimal directValue = BigDecimal.valueOf(12.35);

// 加法已在 double 中完成，之后再包装不能重做十进制加法
double combined = 0.2 + 0.4;
BigDecimal afterDoubleAddition = BigDecimal.valueOf(combined);

// 需要十进制计算时，两个操作数先进入 BigDecimal
BigDecimal decimalAddition = new BigDecimal("0.2")
        .add(new BigDecimal("0.4"));

但 combined 的加法已经在 double 中完成。再调用 valueOf，只能转换现有结果，不能回到最初的两个十进制操作数重新计算。按示例表达式，afterDoubleAddition 与 decimalAddition 在数值上不同。

另一个取舍是数据来源本就具有测量误差时，不应仅靠换类型就宣称获得了无限精度。BigDecimal 能表达和控制十进制计算，但不能改变传感器精度、上游近似或业务容差。

如何判断改造结果并继续维护

改造结果应以输入到输出的数值契约判断：十进制文本是否直接进入 BigDecimal，计算是否仍转回 double，缩放在哪一层完成，以及数值比较采用什么规则。不要以“页面看起来只有两位小数”作为唯一依据。

compareTo 用于数值大小比较，而 equals 同时考虑数值与 scale。排查长尾时若混用两者，可能把表示形式不同也当成精度错误。展示格式、数值相等与业务容差应分别定义。

对于批量任务，可以在项目自己的迁移测试中覆盖普通小数、可精确表示的二进制分数、已完成浮点计算的输入，以及需要拒绝的格式和小数位。本文没有执行这类测试；也不把采用 BigDecimal 描述成无成本的性能优化，性能与分配开销需要结合真实负载测量。

setScale 能修复所有 double 误差吗？

不能。它按规则缩放已有值，可能掩盖差异，但无法推断原始意图。应先修正数据入口，再决定何时舍入。

把 double 转成字符串再构造就完全准确了吗？

它可以按现有浮点值的文本表示构造十进制数，不能恢复已经丢掉的输入信息。已有 double 使用 valueOf 更直接。

BigDecimal 是否意味着所有除法都有精确结果？

不是。遇到无法有限展开的十进制商，仍需根据 API 与业务规则指定精度或舍入方式。

依据：BigDecimal 官方 API与Double 官方转换说明。