Math类因基于IEEE 754双精度浮点数，无法精确进行小数运算，如0.1+0.2≠0.3；金融复利、随机百分比四舍五入、double相等判断等场景易出错。
Math类不能做精确小数运算
Java的Math类所有方法都基于double，本质是IEEE 754浮点数，天然存在精度丢失。比如0.1 + 0.2结果不是0.3而是0.30000000000000004，用Math.round()或Math.floor()也改不了这个底层问题。
常见踩坑场景：
-
金融计算中直接用
Math.pow(1.05, 2)算复利，结果带误差 - 用
Math.random() * 100生成百分比再四舍五入，边界值（如99.999999）可能进位错误 - 比较两个
double是否相等时，误用==而不是Math.abs(a - b)
BigDecimal构造必须用字符串，不能用double
用new BigDecimal(0.1)看似合理，实际传入的是0.1000000000000000055511151231257827021181583404541015625——这是double字面量在内存中的真实值。正确做法永远是new BigDecimal("0.1")。
关键细节：
立即学习“Java免费学习笔记（深入）”；
-
BigDecimal.valueOf(double)内部做了Double.toString(d)转换，比直接构造安全，但仍有陷阱：如果d本身是计算结果（如0.1 + 0.2），toString后仍是错误值 - 所有业务中涉及金额、利率、权重等需精确小数的字段，初始化源头就必须是
String或long - 从数据库读取的
DECIMAL字段，JDBC驱动通常返回BigDecimal，此时无需转换；但若用getDouble()再转BigDecimal，就已失真
BigDecimal运算必须指定Scale和RoundingMode
add()、subtract()、multiply()默认保留全部精度，但divide()不指定参数会抛ArithmeticException（除不尽时）。真实业务中几乎都需要显式控制小数位数和舍入方式。
典型用法：
- 货币计算统一用
setScale(2, RoundingMode.HALF_UP)（银行家舍入的常见替代） - 税率计算可能需要
setScale(6, RoundingMode.HALF_EVEN)避免累积偏差 - 避免用
RoundingMode.UP或.DOWN，它们偏向单向，容易引发审计问题
BigDecimal price = new BigDecimal("199.99");
BigDecimal taxRate = new BigDecimal("0.075");
BigDecimal tax = price.multiply(taxRate).setScale(2, RoundingMode.HALF_UP);
// 结果是 "15.00"，不是 "14.99925"Math和BigDecimal混用时注意类型穿透
一旦开始用BigDecimal，就别中途切回double。比如把BigDecimal转成doubleValue()再塞给Math.sqrt()，精度就彻底丢了。
替代方案：
- 开方、幂运算等复杂函数，优先查Apache Commons Math的
BigReal或自实现牛顿迭代（BigDecimal本身不提供） - 简单比较大小用
compareTo()而非doubleValue()再比较，避免NaN或溢出 - 日志打印时用
toPlainString()而不是toString()，防止科学计数法干扰可读性
最常被忽略的一点：数据库字段类型和Java类型要严格对应。定义为DECIMAL(10,2)的列，Java端必须用BigDecimal接收，哪怕你暂时只做加减——因为未来某天加个乘法或除法，double就会悄悄污染整个计算链。
