在进行 Java 高精度加法时，BigDecimal.add() 是绕不开的标准方案。但很多开发者用着用着就容易踩坑——要么精度丢失，要么性能变差。其实关键在于四个字：用对构造方法。下面把核心要点掰开揉碎讲清楚。
构造 BigDecimal 务必使用字符串，避免使用 double
浮点数的二进制误差是精度问题的根源。举个简单的例子：new BigDecimal(0.1) 实际存储的是 0.10000000000000000555...，后面再怎么加都无济于事。正确的做法是 new BigDecimal("123.456")、new BigDecimal("0.1")——采用字符串构造，一清二楚。
很多人图省事用 BigDecimal.valueOf(double)，它内部调用了 Double.toString()，虽然比直接 new 稍微安全一些，但在金融、计费等关键场景中，还是老老实实使用字符串构造，避免留下隐患。
add() 本身不会丢失精度，结果 scale 取较大值
加法天然不会丢失精度，add() 返回的结果小数位数（scale）取两个操作数中较大的那个。例如 new BigDecimal("1.23").add(new BigDecimal("4.5")) 的结果是 "5.73"（scale = max(2,1) = 2）。
与除法不同，加法不需要强制指定 scale，也不会抛异常。但如果你需要统一输出格式（比如金额保留两位小数），那么等所有加法做完后，最后统一调用一次 setScale(2, RoundingMode.HALF_UP)。千万不要在每次 add() 时都调用 setScale()——那样会叠加舍入误差，导致结果越算越偏。
批量累加：控制对象开销，避免给 GC 增加负担
因为 BigDecimal 是不可变的，在循环里写 sum = sum.add(x) 每次都会生成新对象。当数据量达到上万级时，GC 压力便会明显上升。基础写法很简单：
BigDecimal sum = BigDecimal.ZERO; for (var x : list) sum = sum.add(x);——引用复用，旧对象交给 GC，清晰又高效。- 如果数据量巨大（比如几十万条），可以考虑分批合并：每 100～500 个一组先局部累加，再把批次结果相加，从而减少中间对象的数量。
- 如果需要统一舍入规则（比如所有加法按 DECIMAL128 处理），可以预定义一个
MathContext，然后用sum.add(x, mc)替代默认版本。
避免踩这些常见坑
有些写法看似优化，实则引入风险或无效劳动：
- 用
double构造后再加——从源头污染精度，后续再怎么加都无济于事。 - 在循环里反复
setScale()再加——多次舍入，误差累积，结果可能让你怀疑人生。 - 试图缓存中间计算结果（比如
new BigDecimal("123.45")）——除非业务中大量出现完全相同的常量值，否则缓存收益远低于维护成本，不必折腾。 - 混淆
scale和precision：加法只影响 scale（小数位数），不影响有效数字位数。精度控制应通过MathContext或最终setScale()统一处理，不要搞混。
总结一下：字符串构造 + 循环 add + 最终格式化，这套组合拳打好了，高精度加法就稳了。
