1. 从一个让无数人抓狂的等式说起
如果你在浏览器控制台或者任何一门主流编程语言的交互环境里敲下0.1 + 0.2，大概率会得到一个让你怀疑人生的结果：0.30000000000000004。这不是浏览器抽风，也不是语言设计者故意整蛊，而是几乎所有采用 IEEE 754 浮点数标准的系统都会遇到的经典现象。我第一次碰到这个问题的时候还在写一个电商项目，前端计算购物车金额，两个商品单价分别是 0.1 元和 0.2 元，结果合计显示 0.30000000000000004 元，用户截图发到群里，场面一度非常尴尬。
这个问题的核心关键词就是浮点数精度丢失。它不是一个 bug，而是二进制浮点数表示法在面对某些十进制小数时的固有局限。受影响的范围极广：JavaScript、Python、Java、C、Go、Ruby 等语言只要用了双精度浮点数，都会出现类似现象。适合阅读这篇文章的人包括：刚入行的开发者、被金额计算坑过的后端工程师、做数据可视化的前端同学，以及任何对计算机底层表示法好奇的技术爱好者。接下来我会从原理到实操，把这个问题的来龙去脉和解决方案彻底讲清楚。
2. 为什么 0.1 + 0.2 会翻车
2.1 十进制小数在二进制世界的尴尬处境
要理解这个问题，得先回到计算机最底层的存储方式。计算机用二进制存储一切，整数转换很直接，但小数部分采用的是“乘 2 取整”的方法。拿 0.1 举例，转换过程是这样的：0.1 乘以 2 得 0.2，整数部分为 0；0.2 乘以 2 得 0.4，整数部分为 0；0.4 乘以 2 得 0.8，整数部分为 0；0.8 乘以 2 得 1.6，整数部分为 1；0.6 乘以 2 得 1.2，整数部分为 1；0.2 乘以 2 又回到了 0.4。你会发现这个循环永远不会结束，0.1 在二进制里是一个无限循环小数，写作0.000110011001100110011...。
这就像十进制里 1/3 = 0.3333... 永远写不完一样，只不过换了个进制。计算机的存储空间有限，双精度浮点数只有 64 位，其中尾数部分 52 位，所以必须截断。截断就意味着近似，近似就意味着误差。0.2 同样如此，它在二进制里也是无限循环的。两个带有微小误差的数相加，误差累积，最终结果就偏离了我们期望的 0.3。
2.2 IEEE 754 双精度浮点数的存储结构
IEEE 754 双精度浮点数的 64 位被分成三个部分：1 位符号位、11 位指数位、52 位尾数位。符号位决定正负，指数位决定数量级，尾数位决定有效数字。对于 0.1 来说，它的二进制科学计数法表示为 1.100110011...×2^(-4)，指数是 -4，加上偏移量 1023 后存储为 1019 的二进制。尾数部分只能存 52 位，后面的循环部分被舍入。
这里有一个关键点：舍入不是简单的截断，而是采用“就近舍入，偶数优先”的规则。这个规则本身是为了减少累积误差，但它无法消除误差。0.1 实际存储的值大约是 0.1000000000000000055511151231257827021181583404541015625，0.2 实际存储的值大约是 0.200000000000000011102230246251565404236316680908203125。两者相加得到 0.3000000000000000444089209850062616169452667236328125，再经过一次舍入，最终显示为 0.30000000000000004。
2.3 为什么有些小数运算看起来又是对的
很多人会问：那为什么0.5 + 0.25就等于0.75，一点问题都没有？原因很简单，0.5 是 2 的 -1 次方，0.25 是 2 的 -2 次方，它们都能用有限位二进制精确表示。同理，0.125、0.0625 这些以 2 的负整数次幂为分母的分数，在二进制里都是“干净”的。问题只出现在那些分母含有非 2 质因子的分数上，比如 0.1 = 1/10，分母 10 含有质因子 5，所以无法精确表示。
这个规律可以帮我们快速判断：一个十进制小数能否被二进制浮点数精确表示，取决于它化成分数后分母是否为 2 的幂。如果是，精确；如果不是，近似。这个判断方法在实际开发中非常实用，能让你提前预判哪些计算可能出问题。
3. 精度丢失的真实影响与业务风险
3.1 金额计算场景下的致命问题
金额计算是精度丢失影响最严重的领域。假设你在做一个订单系统，商品 A 价格 19.9 元，商品 B 价格 0.1 元，用户用了 20 元优惠券。如果直接用浮点数计算19.9 + 0.1 - 20，结果可能不是 0，而是-3.552713678800501e-15或者7.105427357601002e-15这样的极小值。这个值在判断“是否还需要支付”时，如果写成if (remaining > 0)，就会误判用户还需要补款，哪怕只是 0.000000000000003 元。
更危险的是累加场景。一个购物车有 100 个商品，每个商品价格都是 0.1 元，用浮点数累加 100 次，结果可能是 9.99999999999998 而不是 10。如果这个值用来和用户支付的 10 元比较，系统会认为用户少付了 0.00000000000002 元，从而拒绝订单。这种问题在测试环境可能因为数据量小而不出现，一到生产环境就爆发。
3.2 比较运算中的隐形陷阱
浮点数比较是另一个重灾区。很多新手会写if (a + b === 0.3)这样的代码，结果永远为 false。正确的做法是判断两个数的差值是否小于某个极小值，也就是所谓的“epsilon 比较法”。但 epsilon 取多少也有讲究：取 1e-10 可能太宽松，取 1e-15 可能太严格。通常建议根据业务精度要求来定，金额场景一般取 1e-8 或更小。
还有一个容易被忽略的点：NaN和Infinity的比较。NaN === NaN永远是 false，必须用Number.isNaN()来判断。0.1 + 0.2虽然不等于 0.3，但它是一个正常的有限数，不是 NaN，所以不能用isNaN来检测精度问题。这个区分很重要，我见过有开发者试图用isNaN(0.1 + 0.2 - 0.3)来判断是否精度丢失，结果当然是 false，因为差值是一个极小的非零数，不是 NaN。
3.3 不同语言的表现差异
虽然 IEEE 754 是通用标准，但不同语言在输出和计算细节上还是有差异。JavaScript 的Number类型就是双精度浮点数，0.1 + 0.2输出0.30000000000000004。Python 的float也是双精度，但print(0.1 + 0.2)输出0.30000000000000004，而repr()可能显示更多位数。Java 的double同样如此，但System.out.println(0.1 + 0.2)输出0.30000000000000004。
有意思的是，有些语言在格式化输出时会做“美化”，比如保留一定位数后看起来就像 0.3。但这只是显示层面的处理，底层存储的值并没有变。如果你把这个值再参与后续计算，误差依然存在。所以千万不要被格式化输出迷惑，以为问题解决了。
4. 解决精度问题的几种实战方案
4.1 整数运算法：最简单也最可靠
最直接的思路是把小数转换成整数再计算。金额场景下，把元转换成分，0.1 元变成 10 分，0.2 元变成 20 分，10 + 20 = 30 分，再除以 100 得到 0.3 元。这个方法简单粗暴，但非常有效。关键在于转换时要确保精度，比如Math.round(0.1 * 100)得到 10，而不是0.1 * 100直接得到10.000000000000002。
整数运算法的适用范围是小数位数固定的场景，比如金额通常保留两位小数，长度保留三位小数等。如果小数位数不固定，比如科学计算中的任意精度，这个方法就不适用了。另外要注意整数溢出的问题，JavaScript 的Number安全整数范围是2^53 - 1，大约是 900 万亿，对于大多数金额场景够用，但如果涉及超大数值，需要考虑BigInt。
4.2 使用专门的十进制库
如果不想自己处理整数转换，可以用现成的十进制库。JavaScript 生态里有decimal.js、big.js、bignumber.js等，Python 有内置的decimal模块，Java 有BigDecimal。这些库内部用十进制存储和运算，能精确表示十进制小数，从根本上避免二进制浮点数的精度问题。
以 Python 的decimal为例，用法是from decimal import Decimal，然后Decimal('0.1') + Decimal('0.2')得到Decimal('0.3')。注意这里必须用字符串初始化，如果写成Decimal(0.1)，传入的已经是浮点数，精度已经丢了。这个坑我踩过，当时调试了半天才发现问题出在初始化方式上。
4.3 四舍五入与格式化输出
对于只是显示需求的场景，可以在最后一步做四舍五入。JavaScript 里可以用toFixed(2)把0.30000000000000004格式化成"0.30"。但要注意toFixed返回的是字符串，而且它的舍入规则在某些边界情况下可能不符合预期，比如(1.005).toFixed(2)得到"1.00"而不是"1.01"，因为 1.005 实际存储的值略小于 1.005。
更稳妥的做法是用Math.round配合乘除法，比如Math.round(num * 100) / 100。但同样要注意，num * 100可能已经引入了误差。所以如果对精度要求极高，还是建议用整数运算或十进制库，格式化只作为最后的展示层处理。
4.4 方案对比与选型建议
| 方案 | 精度 | 性能 | 易用性 | 适用场景 |
|---|---|---|---|---|
| 整数运算法 | 高 | 高 | 中 | 金额、固定小数位 |
| 十进制库 | 极高 | 中 | 高 | 金融、科学计算 |
| 四舍五入 | 中 | 高 | 高 | 仅展示、非关键计算 |
| epsilon 比较 | 中 | 高 | 中 | 浮点数相等判断 |
选型时主要看业务对精度的要求。普通展示场景，四舍五入就够了；涉及金额交易，必须用整数运算或十进制库；科学计算场景，通常用十进制库或专门的数值计算库。性能方面，整数运算最快，十进制库因为要维护十进制结构会慢一些，但在大多数业务场景下差异可以忽略。
5. 实操演练：从踩坑到填坑的完整过程
5.1 复现问题：一个简单的购物车计算
我们先写一段会出问题的代码。假设用 JavaScript 实现一个购物车总价计算：
const items = [ { name: '商品A', price: 0.1, quantity: 3 }, { name: '商品B', price: 0.2, quantity: 2 }, { name: '商品C', price: 0.3, quantity: 1 } ]; let total = 0; items.forEach(item => { total += item.price * item.quantity; }); console.log(total); // 输出 0.7000000000000001期望的总价是 0.1×3 + 0.2×2 + 0.3×1 = 0.3 + 0.4 + 0.3 = 1.0，但实际输出是 0.7000000000000001。这个误差虽然小，但在对账时会导致问题。
5.2 用整数运算法修复
把价格转换成分，计算完再转回元：
const items = [ { name: '商品A', priceInCents: 10, quantity: 3 }, { name: '商品B', priceInCents: 20, quantity: 2 }, { name: '商品C', priceInCents: 30, quantity: 1 } ]; let totalInCents = 0; items.forEach(item => { totalInCents += item.priceInCents * item.quantity; }); const total = totalInCents / 100; console.log(total); // 输出 0.7这里的关键是价格在录入时就以分为单位存储，避免了浮点数转换。如果原始数据是元，可以用Math.round(price * 100)转换，但要确保原始价格的精度不超过两位小数。
5.3 用 decimal.js 处理复杂场景
如果业务涉及折扣、税率等复杂计算，整数运算可能不够灵活，这时候可以用 decimal.js：
import Decimal from 'decimal.js'; const price = new Decimal('19.99'); const discount = new Decimal('0.85'); const tax = new Decimal('1.06'); const finalPrice = price.times(discount).times(tax); console.log(finalPrice.toFixed(2)); // 输出 "18.01"decimal.js 支持链式调用，配置精度和舍入模式也很方便。比如Decimal.set({ precision: 20, rounding: Decimal.ROUND_HALF_UP })可以全局设置精度和舍入规则。注意它的性能比原生浮点数慢，但在金额计算这种低频操作中完全可接受。
5.4 参数选择与精度配置
使用十进制库时，精度配置很关键。精度设得太低，计算结果可能不够准确；设得太高，性能会下降。一般建议比业务需求多保留 2-4 位小数。比如金额场景需要两位小数，精度可以设为 6 或 8。舍入模式通常选ROUND_HALF_UP，也就是我们常说的四舍五入。
还有一个容易忽略的点：除法运算的精度。1 / 3在十进制里也是无限循环小数，十进制库会按照配置的精度截断。所以如果后续还要用这个结果做乘法，误差会放大。建议在除法后立即做舍入，或者根据业务逻辑决定保留多少位。
6. 常见问题排查与避坑指南
6.1 为什么用了 toFixed 还是不对
toFixed的坑在于它的舍入规则和浮点数存储的误差叠加。比如(1.005).toFixed(2)返回"1.00"，因为 1.005 实际存储的值是 1.00499999999999989...，小于 1.005，所以舍入到 1.00。解决办法是先用十进制库处理，或者用Math.round((num + Number.EPSILON) * 100) / 100这种补偿方式，但后者也不是万能的。
6.2 后端返回的金额前端如何处理
后端如果返回19.99这样的浮点数，前端接收后直接计算可能出问题。建议后端返回字符串格式的金额，前端用十进制库解析。如果后端返回的是分单位的整数，前端直接用它计算，最后除以 100 展示。这个约定要在接口文档里写清楚，避免前后端理解不一致。
6.3 数据库存储金额用什么类型
数据库层面，金额字段绝对不能用FLOAT或DOUBLE。MySQL 用DECIMAL(10,2)，PostgreSQL 用NUMERIC(10,2)，这些类型内部是十进制存储，不会丢失精度。如果已经用了浮点类型，迁移时要小心，因为历史数据可能已经存在误差，需要评估影响范围。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 0.1+0.2≠0.3 | 二进制浮点数精度限制 | 控制台直接计算 | 整数运算或十进制库 |
| toFixed 结果不符预期 | 浮点数存储误差 | 打印原始值 | 十进制库处理后格式化 |
| 累加结果偏差 | 误差累积 | 逐步打印中间值 | 整数累加或十进制库 |
| 比较运算失败 | 浮点数不精确 | 打印差值 | epsilon 比较或十进制库 |
| 数据库金额对不上 | 字段类型为浮点 | 检查表结构 | 改为 DECIMAL/NUMERIC |
6.5 独家避坑经验
我在实际项目中总结了几条经验。第一，金额字段在数据库、后端、前端三层都要用十进制或整数，任何一层用浮点数都会前功尽弃。第二，接口传输金额用字符串或整数分，不要用浮点数，JSON 里的数字默认是双精度，传 19.99 可能变成 19.989999999999998。第三，单元测试里要专门加精度测试用例，比如expect(0.1 + 0.2).toBeCloseTo(0.3, 10)，用toBeCloseTo而不是toBe。
还有一个小技巧：如果只是做展示，可以在格式化时多保留几位再截断，比如先toFixed(4)再取前几位，这样能避免一些边界情况。但这个方法是治标不治本，关键计算还是要用十进制方案。
7. 不同技术栈下的精度处理实践
7.1 JavaScript 生态的选型
JavaScript 里处理精度问题，首选decimal.js或big.js。decimal.js功能更全，支持三角函数、对数等高级运算，体积也更大；big.js更轻量，只支持基本四则运算，适合只需要加减乘除的场景。如果项目用 TypeScript，这两个库都有类型定义。另外bignumber.js也是一个选择，API 和decimal.js类似。
如果不想引入第三方库，可以用BigInt做整数运算，但BigInt不支持小数，需要自己管理小数点位置。这个方法适合对包体积敏感的场景，比如移动端 H5 页面。
7.2 Python 的 decimal 模块
Python 内置的decimal模块功能强大，支持上下文管理、精度设置、舍入模式等。用法上要注意用字符串初始化，Decimal('0.1')而不是Decimal(0.1)。还可以用getcontext().prec = 10设置全局精度。在 Django 等框架里，DecimalField底层就是Decimal，用起来很方便。
7.3 Java 的 BigDecimal
Java 的BigDecimal是处理金额的标准方案。创建时用new BigDecimal("0.1")而不是new BigDecimal(0.1)。运算时用add、subtract、multiply、divide方法，除法要指定精度和舍入模式，否则可能抛ArithmeticException。比较用compareTo而不是equals，因为equals会比较精度，new BigDecimal("0.1")和new BigDecimal("0.10")用equals比较返回 false。
7.4 跨语言协作的约定
前后端分离的项目，金额传输建议用字符串。后端返回{"price": "19.99"}，前端用十进制库解析。如果后端是 Java，BigDecimal序列化成 JSON 时默认是数字，可能丢失精度，需要配置成字符串输出。这个配置在 Jackson 里可以用@JsonSerialize(using = ToStringSerializer.class)实现。
8. 写在最后的一些个人体会
精度问题看似是个小问题，但它在实际项目中的破坏力不容小觑。我见过因为金额计算误差导致对账差几分钱，财务追着开发查了一整天的案例；也见过因为浮点数比较失败，导致优惠券无法使用的线上事故。这些问题的根源都在于对浮点数表示法的理解不够深入。
解决这个问题的关键不是记住某个库的 API，而是建立“金额不用浮点数”的意识。从数据库设计到接口定义，从后端计算到前端展示，每一层都要贯彻这个原则。一旦形成习惯，精度问题就会远离你的项目。
另外，不要试图用“四舍五入”来掩盖所有问题。四舍五入只是展示层的补救措施，底层计算必须精确。就像盖房子，地基没打好，墙面刷得再漂亮也经不起考验。精度处理就是软件开发的地基之一，值得每个开发者认真对待。
