还记得第一次写购物车结算功能时，我信心满满地用double类型计算总价。用户买了三件0.1元的商品，系统却显示总价是0.30000000000000004元。那个瞬间，我深刻理解了什么叫“差之毫厘，谬以千里”。
浮点数精度问题的尴尬场景
浮点数在计算机中的存储方式就像用有限的水杯去装无限的小数。0.1这个看似简单的数字，在二进制世界里变成了无限循环小数。银行系统中，如果利息计算出现0.005元的误差，乘以百万用户就是五千元的差额。电商平台的优惠券计算，税务系统的税款统计，这些场景下微小的误差都可能引发严重后果。
我见过一个真实案例：某财务软件因为使用double计算年终奖，导致员工实际到手金额与应发金额相差几分钱。虽然数额不大，但员工对公司的信任感大打折扣。这种精度问题在测试阶段很难发现，往往要到生产环境才会暴露。
BigDecimal的诞生背景与优势
BigDecimal的出现就像给数字计算配了一把精准的游标卡尺。它采用基于字符串的构造方式，完全避开了二进制浮点数的精度陷阱。每个数字都被完整地存储，计算过程严格遵循数学规则。
这个设计确实非常巧妙。BigDecimal不仅解决了精度问题，还提供了丰富的舍入控制选项。你可以指定计算时保留几位小数，采用哪种舍入方式。这种精细控制让它在金融、科学计算等领域大放异彩。
实际开发中的典型应用场景
在电商领域，商品价格计算必须分毫不差。促销活动的满减、折扣、优惠券叠加，这些复杂计算都需要BigDecimal来保证准确性。想象一下双十一期间，任何计算错误都可能造成巨大损失。
金融行业更是BigDecimal的主战场。从简单的存取款业务到复杂的衍生品定价，每一分钱都要精确计算。我记得参与过一个外汇交易项目，汇率通常有4位以上小数，使用BigDecimal才能确保换算结果的准确性。
税务系统同样离不开BigDecimal。增值税计算往往涉及多个税率和抵扣项，任何舍入误差都会影响最终纳税金额。这些场景都在提醒我们：在需要精确计算的领域，BigDecimal不是可选项，而是必选项。
或许你会觉得这些场景离自己很远。但当你开始接触真实项目时，很快就会明白为什么老程序员总是强调“金额计算必须用BigDecimal”。这个经验教训，是用无数个深夜调试换来的。 BigDecimal price = new BigDecimal("19.99");
BigDecimal a = new BigDecimal("10.50"); BigDecimal b = new BigDecimal("3.20");
BigDecimal sum = a.add(b); // 13.70 BigDecimal difference = a.subtract(b); // 7.30 BigDecimal product = a.multiply(b); // 33.600
BigDecimal principal = new BigDecimal("10000"); BigDecimal annualRate = new BigDecimal("0.035"); BigDecimal days = new BigDecimal("180");
// 利息 = 本金 × 年利率 × 天数 ÷ 365 BigDecimal interest = principal.multiply(annualRate)
.multiply(days)
.divide(new BigDecimal("365"), 4, RoundingMode.HALF_UP);
// 不推荐的做法 BigDecimal num1 = new BigDecimal(0.1);
// 推荐的做法
BigDecimal num2 = new BigDecimal("0.1");