new bigdecimal(double) 会继承 double 的二进制精度缺陷，导致如 0.1 变为冗长近似值；bigdecimal.valueof(double) 通过 double.tostring() 获取最短十进制字符串再构造，得到精确值；但若 double 本身已含误差，则仍需从字符串或整数源头构建。
直接用 BigDecimal(double) 构造函数会继承 double 本身的二进制浮点表示缺陷，导致意外精度丢失；而 BigDecimal.valueOf(double) 内部先将 double 转为 long 或科学计数形式再构造，避免了这种问题。
为什么 new BigDecimal(0.1) 不等于 0.1？
double 类型无法精确表示十进制小数（如 0.1），它在内存中实际存储的是一个近似值（例如 0.1000000000000000055511151231257827021181583404541015625）。当你用 new BigDecimal(0.1)，它会**忠实地把那个近似值转成 BigDecimal**，结果不是你期望的 “0.1”，而是那个冗长的二进制近似值。
BigDecimal.valueOf(double) 是怎么解决的？
这个静态方法不直接用 double 的二进制位构造，而是调用 Double.toString(d) 获取其“最短的、能唯一确定该 double 值”的十进制字符串表示（即人类可读且无歧义的写法），再用 new BigDecimal(String) 构造。例如：
-
Double.toString(0.1)返回"0.1"（不是近似值） -
BigDecimal.valueOf(0.1)等价于new BigDecimal("0.1") - 结果是精确的十进制 0.1，没有额外尾数
什么情况下仍要避免用 valueOf(double)？
它只是“缓解”而非“根除”问题——前提是你的 double 值本身来自可靠来源。如果 double 已经是计算误差累积的结果（比如多次浮点运算后得到的 0.30000000000000004），valueOf 仍会把它“如实转成”那个带误差的字符串（如 "0.30000000000000004"）。此时更稳妥的做法是：
- 从原始字符串或整数开始：用
new BigDecimal("0.1")或BigDecimal.valueOf(1).divide(BigDecimal.valueOf(10)) - 若必须从浮点数出发，且知道它本应代表某个简单小数，可配合
setScale四舍五入（但需明确业务含义）
一句话总结推荐做法
永远优先用 BigDecimal.valueOf(double) 替代 new BigDecimal(double)；但更理想的是，从源头避免 double，直接用字符串或整数构造 BigDecimal。
