端经典面试题：为什么 0.1 + 0.2 !== 0.3？

前端经典面试题为什么 0.1 0.2 ! 0.3在 JavaScript 控制台中输入以下代码console.log(0.10.2);// 0.30000000000000004console.log(0.10.20.3);// false这一刻很多初学者的世界观崩塌了“难道计算机连小学数学都算不对吗”当然不是。这背后涉及计算机组成原理中浮点数的存储机制。今天我们就来揭开这个“精度丢失”的神秘面纱。 目录 现象不仅仅是 JS 根源十进制与二进制的“翻译”困境 标准IEEE 754 双精度浮点数 过程0.1 和 0.2 是如何变成 0.3000…4 的️ 解决方案如何在工程中处理精度问题 总结1. 现象不仅仅是 JS首先你要知道这不是 JavaScript 的 Bug而是几乎所有遵循 IEEE 754 标准的编程语言的共同特性。你可以尝试在 Python、Java、C 甚至计算器中运行# Pythonprint(0.10.2)# 0.30000000000000004// JavaSystem.out.println(0.10.2);// 0.30000000000000004结论只要使用双精度浮点数Double就会遇到这个问题。2. 根源十进制与二进制的“翻译”困境计算机底层只认识0和1二进制。当我们写0.1时计算机需要把它转换成二进制存储。❌ 整数转换完美十进制整数转二进制通常很完美。例如十进制5- 二进制101。没有精度损失。⚠️ 小数转换无限循环十进制小数转二进制采用的是“乘 2 取整顺序排列”法。让我们试着把0.1转换成二进制0.1 × 2 0.2 0.1 \times 2 0.20.1×20.2- 取整00.2 × 2 0.4 0.2 \times 2 0.40.2×20.4- 取整00.4 × 2 0.8 0.4 \times 2 0.80.4×20.8- 取整00.8 × 2 1.6 0.8 \times 2 1.60.8×21.6- 取整10.6 × 2 1.2 0.6 \times 2 1.20.6×21.2- 取整10.2 × 2 0.4 0.2 \times 2 0.40.2×20.4- 取整0(注意这里回到了步骤 2开始循环)所以0.1 的二进制表示是0.0001100110011001100110011... ( 0011 无限循环 ) 0.0001100110011001100110011... (0011 \text{ 无限循环})0.0001100110011001100110011...(0011无限循环)同理0.2 的二进制也是无限循环的0.001100110011001100110011... ( 0011 无限循环 ) 0.001100110011001100110011... (0011 \text{ 无限循环})0.001100110011001100110011...(0011无限循环)核心问题计算机的内存是有限的通常是 64 位它存不下无限循环的小数。因此它必须截断舍入。这一截断就产生了精度丢失。3. 标准IEEE 754 双精度浮点数JavaScript 中的Number类型遵循IEEE 754 双精度浮点数标准占用64 位8 字节。这 64 位被分为三部分部分位数作用符号位 (Sign)1 bit0 表示正1 表示负指数位 (Exponent)11 bits科学计数法的指数部分尾数位 (Mantissa/Fraction)52 bits有效数字部分精度所在关键点尾数只有52 位。当二进制小数超过 52 位时超出的部分会被舍入通常是“0 舍 1 入”。这就是误差产生的地方。4. 过程0.1 0.2 是如何变成 0.3000…4 的虽然手动计算 64 位二进制非常复杂但我们可以简化理解这个过程存储阶段0.1被转换为二进制并截断存储为近似值A AA。0.2被转换为二进制并截断存储为近似值B BB。此时A AA和B BB都已经不等于真实的 0.1 和 0.2 了存在微小误差。运算阶段计算机执行A B A BAB。由于二进制对齐指数等操作可能会产生更多的低位误差。输出阶段将结果的二进制转换回十进制显示。最终结果变成了0.30000000000000004。直观理解就像你用只有两位小数的计算器算1 / 3 1 / 3 1/3 1/31/31/3。1 / 3 ≈ 0.33 1/3 \approx 0.331/3≈0.330.33 0.33 0.66 0.33 0.33 0.660.330.330.66而真实结果是0.666... 0.666...0.666...这里的0.00000000000000004就是那个被舍去的“尾巴”累积出来的误差。5. ️ 解决方案如何在工程中处理精度问题既然知道了原理我们在实际开发中尤其是涉及金额计算时该如何避免坑呢✅ 方案一转为整数计算推荐用于金额这是最常用、最稳妥的方法。将小数放大为整数进行运算然后再缩小。// 错误做法console.log(0.10.2);// 0.30000000000000004// 正确做法乘以 10 的 N 次方转为整数运算functionadd(num1,num2){constbase10;// 根据小数位数决定这里假设最多1位小数return(num1*basenum2*base)/base;}console.log(add(0.1,0.2));// 0.3注意对于更复杂的场景建议使用专门的库如decimal.js或big.js它们能处理任意精度的计算。✅ 方案二使用toFixed格式化仅用于展示如果你只需要展示结果不关心内部逻辑可以使用toFixed。注意toFixed返回的是字符串且在不同浏览器下舍入行为可能略有差异虽现代浏览器已统一。constresult0.10.2;console.log(result.toFixed(1));// 0.3console.log(Number(result.toFixed(1)));// 0.3 (转回数字)✅ 方案三设置误差范围Epsilon在比较两个浮点数是否相等时不要直接用而是判断它们的差值是否小于一个极小的数机器精度。functionisEqual(num1,num2){returnMath.abs(num1-num2)Number.EPSILON;}console.log(isEqual(0.10.2,0.3));// trueNumber.EPSILON是 JavaScript 中能表示的最小差值约为2.22 × 10 − 16 2.22 \times 10^{-16}2.22×10−16。✅ 方案四使用 BigInt 或专用库对于极高精度的科学计算或金融级应用直接使用BigDecimal类似的库如decimal.js。importDecimalfromdecimal.js;constanewDecimal(0.1);constbnewDecimal(0.2);console.log(a.plus(b).toString());// 0.3 总结关键点说明根本原因十进制小数如 0.1在二进制中是无限循环的存储限制IEEE 754 双精度只有52 位尾数必须截断影响范围所有遵循 IEEE 754 的语言JS, Java, Python, C 等最佳实践金额计算务必转为整数或使用专用库比较技巧使用Math.abs(a - b) EPSILON代替 博主寄语计算机不会犯错它只是太“直男”了——它只能处理有限的二进制位。作为开发者我们的职责就是理解它的局限性并用工程化的手段去弥补它。记住口诀浮点运算有误差二进制里无尽头。金额计算转整数比较大小用阈值。第三方库来帮忙精准无误不用愁。希望这篇文档能帮你彻底搞懂浮点数精度问题如果有疑问欢迎在评论区留言。喜欢这篇文章吗记得点赞、收藏、转发哦❤️