新手第一次踩进浮点数这个话题，十有八九是从0.1 + 0.2不等于0.3开始的。我记得自己第一次在控制台里看到0.30000000000000004的时候，第一反应是“语言出 bug 了”，第二反应是“是不是精度设置没写对”，折腾半天才发现——原来不是工具的问题，是浮点数天生就这样。这个坑，几乎所有写代码的人都踩过，而且踩完之后很少有人愿意停下来把原理彻底弄清楚，大多数人是记住一句“别用浮点数比较相等”就跑了。
这篇文章想做的，就是把这层窗户纸捅破。我会从二进制表示说起，把 IEEE 754 的存储机制拆开，再结合实际工程里最容易出问题的几个场景，给出我这些年积累下来的判断方法和解决方案。无论你是做后端接口、前端展示、数据分析，还是写科学计算脚本，这篇文章都值得从头到尾看一遍。
1. 为什么 0.1 + 0.2 不是 0.3：先搞清楚“十进制”和“二进制”的错位
1.1 十进制里干净的数，二进制里可能是无限循环
我们从小到大用的都是十进制，所以直觉上0.1就是一个干干净净的小数，不多不少，正好是十分之一。但计算机内部不是这么存数的，它只有 0 和 1，处理小数时用的是二进制的科学计数法。问题是：十进制里能精确表示的数，换成二进制之后，不见得还是精确的。
举个例子，1/3在十进制里是0.33333...，无限循环，我们只能取一个近似值。同样的道理，十进制里的0.1，换算成二进制之后是0.0001100110011001100110011001100110011001100110011001101...，一个无限循环的二进制小数。注意这个循环节是0011，永远写不完。
你可能会想，计算机不是有那么多位去存吗？存个近似值不就行了吗？问题就在于“近似”这件事本身有代价。当我们把有限位数的近似值存下来，再进行加减乘除，误差就会在这个基础上不断累积和放大，最终在屏幕上展现出让人看不懂的结果。
1.2 0.1 在二进制里到底长什么样
我们来手动算一下0.1的二进制展开。小数部分转换成二进制的方法是“乘 2 取整”：把0.1乘以 2，得到0.2，取整数部分 0；继续用0.2乘以 2，得到0.4，取整 0；再乘 2 得到0.8，取整 0；再乘 2 得到1.6，取整 1，剩下0.6；再乘 2 得到1.2，取整 1，剩下0.2……
这时候你会看到0.2重新出现了，也就是说后面就该开始循环了。整个二进制结果是：
0.0001100110011001100110011001100110011001100110011001101...只要把这个序列截断到有限长度，就必然产生误差。IEEE 754 双精度浮点数只给小数部分留了 52 位，所以0.1存进去之后，实际值并不是精确的0.1，而是一个非常接近但稍微大了一丢丢的数——具体来说是0.1000000000000000055511151231257827021181583404541015625。
这个数看起来只差一点点，但它是真实存在的误差。0.2同样也有它自己的近似误差，两个有误差的数相加，结果自然偏离了0.3的理论值，最后得到0.30000000000000004，就是这么来的。
1.3 一个反问：为什么 0.5 就没事？
理解了上面的机制，你会想到另一个问题：0.5为什么能精确表示？因为0.5在二进制里是0.1，刚好写完了，不需要循环。类似的还有0.25（二进制0.01）、0.125（二进制0.001）、0.0625（二进制0.0001）。
这里就能总结出一条规律：一个十进制小数能精确表示，当且仅当它能写成若干个 2 的负幂次之和，且不产生无限循环。分母只包含质因数 2 的分数，在二进制里都是干净利落的；只要分母里出现了 5 这个质因数，比如 1/5、1/10、1/20，那么就一定会无限循环，只能存近似值。
这条规律理解了，浮点数的大半疑惑就解开了。
2. IEEE 754 的存储机制：计算机到底怎么把一个小数塞进内存
2.1 位数分配：符号位、指数位、尾数位
IEEE 754 是行业通用的浮点数标准，几乎所有 CPU 和主流编程语言都遵循它。双精度浮点数（double类型）总共占 64 位，分配方式大致是：第 1 位是符号位，表示正负；接下来 11 位是指数位；剩下的 52 位是尾数位，也叫有效数字位。
单精度浮点数（float类型）则更紧凑，32 位里符号位 1、指数位 8、尾数位 23。指数位和尾数位决定了这个数能表示的“范围”和“精度”，两者此消彼长，位数越多，能表达的范围越大，能容纳的有效数字也越多。
用一个表格把常见类型的位预算整理清楚：
| 类型 | 总位数 | 符号位 | 指数位 | 尾数位 | 十进制有效数字 |
|---|---|---|---|---|---|
| 单精度 float | 32 | 1 | 8 | 23 | 约 6~9 位 |
| 双精度 double | 64 | 1 | 11 | 52 | 约 15~17 位 |
| 扩展精度 long double | 80（常见 x86） | 1 | 15 | 64 | 约 18~21 位 |
为什么说是“约”？因为尾数位能表示的有效数字是二进制位的数量，映射到十进制有效数字会有一个换算关系：有效十进制位数 ≈ 尾数位数 × log10(2)。按这个公式算，双精度是52 × 0.3010 ≈ 15.65，也就是说大概保证 15 位十进制数字是可信的，第 16、17 位可能已经出现误差。
2.2 规范化与尾数的“隐藏位”
浮点数的存储并不像一般人想的那样，把小数点前后写开存。IEEE 754 采用的是科学计数法：任何数都写成±1.xxxx × 2^y的形式。注意这里的整数部分永远是 1，既然永远是 1，就不需要单独存储，这就是所谓的“隐藏位”。
举个例子，双精度里二进制数1.1001101... × 2^3，实际存储时只存1001101...这一串尾数，前面的1.在读取时自动补上。这样一来，52 位尾数实际上贡献了 53 位的有效精度，对精度的利用提升了接近一倍。这个设计在当年是非常巧妙的，现在看起来仍然觉得很聪明。
2.3 指数偏置，为什么不用补码
指数部分的设计也很有意思。IEEE 754 没有用常见的补码来表示负数指数，而是用了“偏置值”：双精度的指数位有 11 位，能表示 0 到 2047，但实际上真正的指数范围是 -1022 到 1023。存储时，把真实指数加上一个固定偏置 1023，比如真实指数是 3，存储值就是 1026。
这样设计的目的是让浮点数的正负数比较可以通过直接比较存储值的整数大小来实现，而且让浮点数的“阶”从小到大排列，配合规范化之后，正数从小到大正好对应存储位的从小到大，硬件排序非常方便。这个偏置设计对性能友好，也是当年标准制定者的智慧。
指数部分还有一些特殊用途：指数位全 0 表示非规范化数或真正的 0，全 1 配合尾数位可以表示无穷大和 NaN。这些特殊值在工程中经常悄悄出现，后面单独说。
3. 浮点数运算会踩的三种典型陷阱
3.1 直接比相等的陷阱：0.30000000000000004 是怎么破坏逻辑的
先说最经典的：浮点数比较。很多人会在业务代码里写if (x === 0.3)或者if (a + b === 1.0)，然后莫名奇妙地发现条件不成立。原因我们已经清楚了，0.1 + 0.2的结果实际上是0.30000000000000004，拿它去和0.3比对，永远不相等。
我在实际项目里见过一个更有迷惑性的场景。某个价格区间判断的逻辑，前端判断用户输入金额是否落在了[0, 0.1]区间内，结果用户输0.07，计算0.04 + 0.03之后再用<= 0.1去判断，偶尔会卡在边界上——因为0.04 + 0.03的结果可能是0.07的近似值，恰好大于0.1的近似值，导致边界判断失败。
这种情况，正确的做法是引入“容差比较”：两个浮点数相等，当且仅当它们的差值绝对值小于一个足够小的阈值。工程上一般用epsilon，比如双精度可以用1e-9或者1e-12，根据具体业务量级调整。比较代码可以写成：
def nearly_equal(a, b, epsilon=1e-9): return abs(a - b) <= epsilon * max(abs(a), abs(b))注意上面用了相对容差。如果只写abs(a - b) <= 1e-9，在数值很小或很大的场景下仍然可能误判：数值是1e-20的时候，1e-9的容差相对它太大；数值是1e18的时候，1e-9的容差又太小。所以更稳妥的方式是同时考虑绝对容差和相对容差，成熟库比如 NumPy 的isclose就是这种思路。
3.2 累加误差：循环一百万次之后，结果为什么漂了
比单次比较更隐蔽的是多次运算后的误差累积。单次操作的误差可能只有一点点，但循环累积起来会在数量级上产生肉眼可见的偏差。
举一个常见的例子：假设我们要把0.1累加一万次，理论结果是1000。但如果你真的用双精度浮点数写循环累加，最终结果很可能是1000.0000000001588之类的值。这个差异来自每加一次0.1都会引入一点点近似误差，误差像滚雪球一样越积越大。
解决方案之一是采用Kahan 求和算法。该算法的核心思想是单独维护一个“补偿变量”，把每次加法中被丢弃的低位误差记录下来，在下一轮加回去。用代码表示大概是：
double kahan_sum(double* arr, int n) { double sum = 0.0; double compensation = 0.0; for (int i = 0; i < n; i++) { double y = arr[i] - compensation; double t = sum + y; compensation = (t - sum) - y; sum = t; } return sum; }这个算法在多数场景下能把误差从O(n)降低到接近常数水平，代价只是多几次加减法，性价比极高。不过它也并不是万无一失，当参与运算的数之间量级差异极大时，补偿逻辑本身也可能出现误差，这时需要考虑其他策略，比如先把数据按大小排序，从小加到大。
3.3 大数吃小数：一个巨大的数加一个极小的数，可能等于没加
浮点数的尾数位数有限，意味着它能够表示的相对精度是有限的。如果一个数是1e16，双精度能表示的相邻两个数之间的间隔大约是2左右，也就是说在这个量级下，你加一个1、加一个0.1，都有可能因为量级太小直接被吞掉，计算结果和原来一模一样。
我处理过一个真实场景：某系统在统计日活数据时，用一个 double 变量持续累加每分钟的用户数。数据量一旦过了千万级，精确到个位数的误差就开始出现，虽然单看误差占比很小，但下游做环比计算时，一个本来应该不为零的变化量，计算出来却是 0，直接导致对账对不上。这正是浮点数“大数吃小数”的典型症状。
解决这类问题，方案通常不是继续调整浮点数精度，而是换思路：
- 如果业务本身对精确性有硬性要求，比如金额、库存、计数，那就不要用浮点数，改整数或定点数；
- 如果是统计类场景，尽量用更大单位的整数计数，或者分段累加后再合并；
- 如果必须要用浮点数，可以对数据进行缩放，让参与运算的量级尽量接近。
3.4 特殊值出没：NaN、Infinity、-0.0 带来的连锁问题
浮点数家族里还有几个“诡异成员”：NaN（不是一个数）、正负无穷、以及带符号的零。
NaN最麻烦的地方在于它不参与比较。任何数与NaN比较大小，结果都是false，连NaN === NaN都是false。如果你在一个统计链路里不小心引入了一个NaN，它会在后续累计计算中像病毒一样扩散，并且不会报错，整个结果变成NaN，排查起来非常痛苦。所以我在做数值处理函数时都会加上一个检查：输入是否为有限数，是 NaN 或 Infinity 就直接拦截。
-0.0也有自己的脾气。在某些语言里，0.0 === -0.0返回true，但1 / 0.0得到Infinity，1 / -0.0得到-Infinity，结果不同。JSON 序列化时，0.0和-0.0的展示也可能不一致。这些边界情况在订单、排名、是否为零的判定逻辑中都可能产生莫名其妙的结果，建议在涉及这类逻辑时统一求绝对值或者做显式的零值归一化。
4. 工程里的选择：什么时候保留浮点，什么时候换方案
4.1 需要精确小数的场景，尽早换成十进制方案
金融系统绝对是浮点数的重灾区。金额计算如果用了double，在利息、手续费、汇率换算等多步计算后，误差会被放大到对不上账的程度。真实的银行计息系统不可能接受一笔利息因为浮点数误差少了一分钱。
处理这类场景，业界成熟的做法是使用十进制小数类型。这类类型在内部把数字当作十进制整数和指数来存储，广泛采用的有：
- Java 中的
BigDecimal - Python 中的
decimal.Decimal - C# 中的
decimal - 数据库中常见的
NUMERIC / DECIMAL字段类型 - JavaScript 生态中可以引入专门的高精度库
以 Python 为例：
from decimal import Decimal x = Decimal("0.1") y = Decimal("0.2") print(x + y) # 输出 0.3，符合十进制直觉注意Decimal("0.1")传入的是一个字符串，而不是Decimal(0.1)。如果直接传浮点数0.1，那么浮点数近似误差已经被提前引入了，再转成Decimal只是把这个误差“原封不动”地保留下来，错误仍然存在。这是我见过很多同学反复踩的坑。
十进制方案也不是没有代价：性能通常比二进制浮点慢不少，内存占用也高。所以在不需要高精度的小数场景里，不要盲目全上 Decimal，做好取舍。
4.2 整数量级的场景，优先用整数
有些业务虽然展示上有小数点，但本质上可以转成整数运算。最常见的例子是货币金额按最小单位“分”存储，所有运算都用整数加减乘除，最后展示时再除以 100。
这种方案的好处是彻底规避浮点误差，性能也更好。电商、支付、计费等系统的核心账务链路基本都是统一用整数分。即使是需要做百分比、折扣等计算，合理的做法也是先把比例换算好再以整数精度参与计算，最终再决定舍入规则。
需要注意的是，整数类型本身也有溢出边界，比如 32 位整数最大值约 21 亿，金额按分存储时，一旦超过就会溢出。在现代语言里，推荐用 64 位整数或者带任意精度的大整数类型，毕竟范围和可靠性更重要。
4.3 舍入规则是个隐形的大坑：银行家舍入了解一下
即使换了 Decimal，舍入规则如果不正确，依然会在边界情况下产生差异。最常见的round函数在不同语言里的实现并不完全一致。比如 Python 3 的round采用“银行家舍入”，也就是“四舍六入五取偶”：round(0.5)是 0，round(1.5)是 2，round(2.5)是 2。
这个规则的用意是让大量舍入操作在统计意义上更加无偏，避免一直向上或向下导致系统性偏差。但很多业务预期不是这样，比如计算税额按四舍五入累进，每一笔都向上取整，这时银行家舍入就会让结果比预期少一分钱。
正确做法是显式指定舍入模式。decimal模块里可以设置ROUND_HALF_UP、ROUND_HALF_DOWN、ROUND_UP等模式，金融场景尤其要明确规则并写进测试。不要在代码里依赖语言默认的舍入行为，这个坑我吃过不止一次。
4.4 展示层的处理：别让用户看到 0.30000000000000004
即便后端计算结果有微小误差，前端展示也绝对不能把这个误差直接抛给用户。用户看到的应该永远是格式化后的合理结果。
在 JavaScript 里，toFixed(2)可以用来控制小数位；Python 里可以用format(value, ".2f")；后端接口返回时也可以主动做一次四舍五入或截断。但这里要强调：展示层的格式化只是“遮丑”，不能替代计算层的正确选择。如果计算层误差已经累积到影响业务逻辑判断，格式化救不了你。
我曾见过一个系统，所有计算结果都是先格式化到两位小数再继续参与后续运算，结果在累计几百笔后，误差被格式化的舍入一步步放大，最终出现对账差异。正确的流程是：全部计算保持高精度，只在最终展示和输出时格式化。
5. 做个浮点数“体检”：一套自查清单和排查经验
5.1 编写代码前，先问自己三个问题
我在 review 代码的时候，遇到涉及小数的逻辑，几乎条件反射式地会问三个问题：
- 这个数值参与的是判断、展示，还是参与计算？
- 这个数值的量级范围是什么？运算链路有多长？
- 如果出现一分钱、一位数的偏差，业务上能不能接受？
这三个问题的答案基本决定了方案路径。如果只是展示且精度要求低，直接格式化即可；如果参与计算且有精确要求，立刻考虑 Decimal 或整数；如果运算链路极长且没有精确要求，Kahan 求和或排序后累加是很好的兜底方案。
5.2 排查浮点问题的三步分析法
当线上出现诡异的数值问题时，我的排查套路是先复现，再定位环节，最后验证修复。
复现阶段，要把用户输入和中间计算结果完整记录下来，最好能在日志里输出精度足够的原始值，而不是格式化后的值。很多问题无法复现，就是因为日志里只保留了两位小数，误差在源头已经被掩盖了。
定位阶段，在关键运算节点前后打印原始位模式或足够位数的小数。我曾经处理过一个电商系统的返利计算问题，把链路拆开后发现错误出现在“折扣率乘以商品金额”这一步：折扣率是一个无限循环小数，乘以金额时误差被放大了。定位过程打印的每一层中间值都有精确到 17 位的输出，一步一步对比出偏差来源。
验证阶段，修改方案后要跑一遍边界测试：包括 0、负数、NaN、极大极小值，以及随机批量数据和理论上精确可表示的值。边界场景比正常场景更容易暴露浮点问题。
5.3 我最后想分享的三条经验
第一，永远不要尝试通过增加显示位数来“修复”浮点数误差。误差是存储层面的问题，显示位数最多只能让它暂时看不见，问题仍然存在。
第二，写测试时，不要用assertEqual(x, 0.1)之类的写法，改用带容差的比较或直接使用精确值。测试如果不写容差，会在某一天因为换个编译器版本、换个运行平台，莫名其妙地失败，而代码本身并没有变。
第三，如果对误差要求特别严格，建议在算法设计阶段就避开浮点数，而不是等问题爆发后再修补。就像盖楼时地基就用钢筋混凝土，而不是等裂缝出现再灌浆。越早做决策，代价越小。
浮点数这个话题看起来只是一个小知识点，但它几乎渗透在每一个软件系统里。从底层 CPU 指令到高层业务逻辑，浮点数的误差最终会以账单、排名、图表、算法结果的形式出现在用户面前。理解了它的原理，再配合合适的方案选型，这些坑其实都是可以提前绕开的。
