<p>JavaScript 中 0.1 + 0.2 !== 0.3 是因 IEEE 754 双精度标准下，0.1 和 0.2 在二进制中为无限循环小数，存储时被截断产生近似值，相加后误差叠加得 0.30000000000000004；应使用 Math.abs(a - b) < Number.EPSILON 进行容差比较。</p>
JavaScript 中的 Number 类型基于 IEEE 754 双精度浮点数标准，这意味着它在表示和运算小数时存在固有精度限制，不是 bug，而是所有遵循该标准的语言共有的特性。
为什么 0.1 + 0.2 !== 0.3？
因为十进制小数 0.1 和 0.2 在二进制中是无限循环小数（类似十进制中 1/3 = 0.333…），无法被双精度浮点数精确存储。它们各自被近似为最接近的可表示值，相加后误差叠加，结果是 0.30000000000000004 而非 0.3。
- 可用
Number.EPSILON判断“是否足够接近”：Math.abs(a - b) - 避免直接用
===比较浮点数，尤其涉及计算结果时 - 调试时可用
(0.1 + 0.2).toFixed(1)或parseFloat((0.1 + 0.2).toFixed(1))得到预期字符串或数值（注意toFixed返回字符串）
整数安全范围：Safe Integer
JavaScript 能**精确表示**的整数范围是 -(2^53 - 1) 到 2^53 - 1，即 Number.MIN_SAFE_INTEGER 到 Number.MAX_SAFE_INTEGER（约 ±9007199254740991）。
- 超出此范围的整数可能丢失精度，例如
9007199254740992 === 9007199254740993返回true - 用
Number.isSafeInteger(n)检查一个值是否在此范围内且为整数 - 处理大整数应考虑
BigInt（需字面量加n后缀，如123n），但注意BigInt与Number不兼容运算
常见陷阱与应对建议
浮点误差会影响金融计算、动画帧控制、数组索引、循环边界等场景，需主动规避：
立即学习“Java免费学习笔记（深入）”；
- 货币计算不用浮点数：统一转为整数（单位：分），再做加减乘除
-
避免累加小浮点数：如
for (let i = 0; i 可能多执行一次或少执行一次，改用整数计数再除： <code>for (let i = 0; i -
使用成熟库辅助：如
decimal.js、big.js处理高精度需求，而非自行封装四舍五入逻辑 -
JSON 序列化不放大问题：
JSON.stringify(0.1 + 0.2)会自动舍入显示为"0.30000000000000004"，但本质仍是那个近似值
几个实用技巧
不依赖魔法数字，用语言本身提供的能力更可靠：
- 取小数位数推荐
Math.round(num * 100) / 100（比toFixed更可控，返回数值） - 判断是否为有效数字：优先用
Number.isFinite()，而非typeof x === 'number' && !isNaN(x) - 解析数字时用
Number()或一元加号+str，比parseInt/parseFloat更严格（后者会忽略尾部非数字字符） - 注意
0和-0在 JS 中不同：Object.is(-0, 0)返回false；1 / -0 === -Infinity
