bigdecimal.valueof(double)能规避double构造函数的精度错觉，因其调用double.tostring()获取最短十进制字符串再构造，如实呈现人类可读形式（如0.1），而非直接映射二进制近似值。
直接用 BigDecimal(double) 构造函数会继承 double 本身的二进制浮点表示误差，导致“明明输的是 0.1，却变成 0.10000000000000000555…”这类问题。而 BigDecimal.valueOf(double) 内部先将 double 转为 long 或科学计数形式的字符串再构造，能还原出该 double 值**最简、最符合人类直觉的十进制表示**，从而规避精度错觉。
为什么 double 构造函数会出问题
BigDecimal(double) 不做任何解释或规整，它忠实地把 double 的二进制 IEEE 754 值直接映射为 BigDecimal——哪怕这个二进制值本就无法精确表示 0.1 这样的十进制小数。结果是：你看到的字面量（如 0.1）在编译时已被转成近似二进制值，BigDecimal 只是把它“如实”记录下来，反而暴露了底层失真。
valueOf() 是怎么解决的
BigDecimal.valueOf(double) 实际调用了 Double.toString(d)，而这个方法遵循 JVM 规范，返回的是“能唯一反向解析回原 double 值的最短十进制字符串”。例如：
-
Double.toString(0.1)→"0.1"（不是"0.10000000000000000555..."） -
Double.toString(0.3 - 0.2)→"0.09999999999999998"（因为0.3-0.2真实结果就是这个double）
然后 valueOf() 拿这个字符串去走 new BigDecimal(String) 路径——这条路径是精确无损的。
正确用法与常见误区
- ✅ 推荐：用
BigDecimal.valueOf(0.1)替代new BigDecimal(0.1) - ✅ 更稳妥：如果原始数据来自字面量或用户输入，优先用字符串构造，如
new BigDecimal("0.1") - ❌ 避免：对计算后的
double结果（如a + b）仍用valueOf()——它只能帮你“干净地表达那个已失真的值”，不能修复计算本身；此时应从源头改用 BigDecimal 运算 - ⚠️ 注意：
valueOf()对NaN、无穷大会抛异常，而new BigDecimal(double)会静默接受（但结果无意义）
一句话总结
BigDecimal.valueOf(double) 不是“修复精度”，而是“合理呈现精度”——它把一个有缺陷的 double，用人类可读、可预期的方式转成 BigDecimal，避免因构造方式不当放大误解。真正需要高精度计算时，应全程使用 BigDecimal 运算，而非依赖 double 中间结果。
