JavaScript数字与IEEE754标准详解

JavaScript 的 Number 类型并非真正的整数或精确小数，而是完全基于 IEEE 754 双精度浮点标准（64 位，1-11-52 结构）的统一浮点表示——这意味着所有数字，包括看似整数的 42，都以带精度限制的二进制浮点形式存储和运算；它能精确表示的整数上限仅为 ±(2⁵³−1)，超出后连续整数开始合并；0、Infinity 和 NaN 均由特定比特模式定义，而非特殊类型；而 0.1 + 0.2 ≠ 0.3 这类“反直觉”结果，根源在于十进制小数在二进制下的无限循环与截断误差。理解这一底层机制，不仅能解释日常开发中的精度陷阱、比较失效和大数失真，更能帮你做出更稳健的技术选型——比如用 BigInt 处理超长 ID、用 EPSILON 替代严格相等、用字符串安全传递高精度数值。

JavaScript 中的 Number 类型完全基于 IEEE 754 双精度浮点格式（64 位），这意味着它没有整数类型，所有数字都是浮点数——哪怕你写 42 或 0，底层也按双精度浮点规则存储和运算。

64 位怎么分配：1-11-52 结构

IEEE 754 双精度格式把 64 位划分为三部分：

• 1 位符号位（sign）：0 表示正，1 表示负
• 11 位指数位（exponent）：偏移量为 1023（即真实指数 = 存储值 − 1023）
• 52 位尾数位（fraction / mantissa）：实际有效数字共 53 位，因为隐含一个前导 1（规格化数）

例如，1.5 的二进制是 1.1，规格化后尾数存 100...0（52 位中只填小数点后部分），指数为 0 → 存储指数 = 1023 → 二进制 01111111111。

能精确表示哪些整数？

由于只有 53 位有效精度，JavaScript 能**精确表示所有绝对值 ≤ 2⁵³ − 1 的整数**（即 Number.MAX_SAFE_INTEGER === 9007199254740991）。超过这个范围，连续整数开始“丢失”：

• 9007199254740991 === 9007199254740992 → true（已不安全）
• Math.pow(2, 53) + 1 === Math.pow(2, 53) → true

注意：“安全”指该整数及其相邻整数都能被唯一、无歧义地表示。超出后，多个整数映射到同一个 double 值。

特殊值如何编码？

IEEE 754 预留了特定比特模式表达非数值：

• 零（±0）：指数全 0 + 尾数全 0；符号位决定正负零（1 / -0 === -Infinity）
• 无穷（±Infinity）：指数全 1 + 尾数全 0
• NaN（Not-a-Number）：指数全 1 + 尾数非全 0；所有 NaN 都不等于自身（NaN === NaN 为 false）

Number.NaN、Infinity、-Infinity 都是这些编码的语义封装，不是魔法常量。

常见陷阱与应对建议

理解底层表示能帮你避开典型问题：

• 小数计算不准：如 0.1 + 0.2 !== 0.3，因 0.1 在二进制中是无限循环小数，只能近似存储 → 比较时用 Math.abs(a - b)
• 大整数截断：ID、时间戳（毫秒级）若超 2⁵³，可能出错 → 用 BigInt 处理大整数，或字符串传输/存储
• 隐式转换误导：+"0.0000001" 得 1e-7，但 +"0.00000001" 仍精确；关键看是否在 53 位精度内可表示

不复杂但容易忽略：JavaScript 的 Number 不是数学实数，而是有限精度浮点近似——把它当作带误差边界的工具，而非精确计算器。

以上就是《JavaScript数字与IEEE754标准详解》的详细内容，更多关于的资料请关注golang学习网公众号！