console.log(0.1 + 0.2) 的输出不是预期的 0.3，而是 0.30000000000000004。对这个问题进行深入研究

IEEE 754 标准的限制

JavaScript 的 Number 类型本质是64 位双精度浮点数（double-precision floating-point），整个 64 位的二进制位被划分为 3 个部分：

部分	位数	作用
符号位（S）	1	0 = 正数，1 = 负数（0.1、0.2 都是正数，所以 S=0）
指数位（E）	11	存储指数值，采用偏移码（偏移量为 1023），表示范围：-1022 ~ +1023
尾数位（M）	52	存储有效数字（小数部分），隐含一个固定的“1”（即尾数实际是 1.M）

浮点数的最终值计算公式为：

$$V = (-1)^S \times (1 + M) \times 2^{(E - 1023)}$$

这个公式是理解所有精度问题的核心——尾数位只有 52 位，超过的部分会被截断/舍入，这是误差的根源。

1.1 那么正常的整数是怎么进行转换的呢？

其核心转换逻辑是 「十进制整数」 -> 「二进制整数」 -> 「规格化二进制」 -> 「映射到 IEEE754 存储结构」。以 3094 为例

步骤 1： 十进制整数 3094 转二进制整数

整数转二进制采用「除 2 取余，逆序排列」规则，对 3094 执行计算：

3094 ÷ 2 = 1547  余 0
1547 ÷ 2 = 773   余 1
773 ÷ 2 = 386    余 1
386 ÷ 2 = 193    余 0
193 ÷ 2 = 96     余 1
96 ÷ 2 = 48      余 0
48 ÷ 2 = 24      余 0
24 ÷ 2 = 12      余 0
12 ÷ 2 = 6       余 0
6 ÷ 2 = 3        余 0
3 ÷ 2 = 1        余 1
1 ÷ 2 = 0        余 1

将余数逆序排列，得到 3094 的二进制：110000010110（共 12 位）。

步骤 2：二进制规格化（适配 IEEE 754 格式）

IEEE 754 要求浮点数必须以「规格化形式」存储，即 1.M × 2^e（M 为尾数字段，e 为指数）。对 3094 的二进制进行规格化：

将二进制 110000010110 的小数点左移 11 位，得到： 110000010110 = 1.10000010110 × 2^11 此时得到关键参数：

• 规格化后的小数部分M：10000010110（去掉开头的固定“1”，仅保留小数部分）
• 指数 e：11（小数点左移的位数）

步骤 3：计算 IEEE 754 的三大字段（符号位、指数位、尾数位）

结合 64 位双精度浮点数的存储规则，逐一推导三大字段：

1. 符号位（S）：3094 是正数，符号位为 0（1 位）。

2. 指数位（E）：IEEE 754 指数位采用「偏移码」，偏移量为 1023。计算方式：E = e + 1023。

代入 e=11，得 E=11+1023=1034。将 1034 转为 11 位二进制：10000001010。

3. 尾数位（M）：尾数位共 52 位，存储步骤 2 得到的 M（10000010110），剩余位数补 0 填充。 最终尾数位：1000001011000000000000000000000000000000000000000000（共 52 位）。

步骤 4：验证存储结果（精确性）

将三大字段组合，得到 3094 的 IEEE 754 完整存储二进制（64 位）： 0 10000001010 1000001011000000000000000000000000000000000000000000

代入 IEEE 754 数值计算公式验证：

$$V = (-1)^S × (1 + M) × 2^{(E - 1023)} = (-1)^0 × (1 + 0.10000010110) × 2^{(1034 - 1023)} = 1.10000010110 × 2^{11} = 3094$$

可见，3094 经 IEEE 754 转换后能被精确存储，无任何误差。这也印证了「53 位以内的整数可被 IEEE 754 精确表示」的结论（3094 的二进制 12 位，远小于 53 位）。

1.2 0.1 与 0.2 的二进制转换过程

十进制小数转二进制的规则是“乘 2 取整，直到小数部分为 0 或达到精度上限”。对 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（开始循环）
... 无限循环，循环节为0011 ...

最终，0.1 的二进制是 0.0001100110011...（无限循环），0.2 的二进制同样是无限循环小数。两者存储时均被截断为近似值，相加后误差被放大，最终结果就是 0.30000000000000004。

第二层原因：JS 的 number 对应的是 C 里面的 double 类型

JS 的 number 类型其实对应的 C 里面的 double 类型，而 C 的 double 类型就是遵循的 IEEE754 标准。所以其实 C 里面也会有问题。

但 JS 当初为什么不设置其他类型等等这些就不用关注了，现在已经是这样的了。

源码对应如下

2.1 规范层面：ECMAScript 标准的明文规定

ECMAScript 规范第 6.1.6 节（The Number Type） 明确指出：

The Number type is a double-precision 64-bit binary format IEEE 754 value (see 6.1.6.1)

这是底层映射的根本依据，所有 JS 引擎必须遵循此规范，而 C/C++的double类型正是 IEEE 754 64 位双精度浮点数的标准实现。

规范原文链接：https://tc39.es/ecma262/#sec-ecmascript-language-types-number-type

2.2 V8 引擎源码（Chrome/Node.js）

V8 是 C++编写的 JS 引擎，Number 对应关系在以下核心文件中清晰可见：

1. HeapNumber 类定义（核心存储）

   • 文件：src/objects/heap-number.h
   • 关键代码：HeapNumber 是 V8 中存储非小整数的对象，内部直接用double value_字段保存数值

   class HeapNumber : public HeapObject {
    public:
     // 存储IEEE 754 64位双精度浮点数的核心字段
     double value() const { return value_; }
     void set_value(double value) { value_ = value; }
    private:
     double value_;  // 8字节，完全对应C的double类型
   };

   链接：https://chromium.googlesource.com/v8/v8/+/main/src/objects/heap-number.h

2. API 层直接暴露 double

• V8 API 中，v8::Number::Value() 返回double；创建 JS 数值用v8::Number::New(isolate, 42.0)，参数直接为double

  Local<Number> num = Number::New(isolate, 3.14);
  double value = num->Value();  // value = 3.14 (C++ double类型)

  链接：https://v8.github.io/api/head/classv8_1_1Number.html

第三层原因：为啥是 IEEE 754 标准，为啥不修复，这个应该是个很明显的问题吧。

3.1 为啥非得选 IEEE 754？—— 没有更好的“通用替代方案”

在 IEEE 754 诞生前（1985 年之前），计算机行业没有统一的浮点数标准：不同厂商的 CPU（如 Intel、Motorola）、不同编程语言的浮点数存储/运算规则都不一样。比如同样计算 0.1+0.2，在 A 品牌电脑上结果是 0.3，在 B 品牌上可能是 0.3000000001，跨平台程序根本无法正常运行。

IEEE 754 的出现就是为了解决这个“混乱问题”，它能成为主流选择，核心有 3 个不可替代的优势：

1. 跨平台/跨语言一致性：它是软硬件都遵循的“通用协议”，无论 Windows/macOS/Linux，还是 x86/ARM 架构，只要支持 IEEE 754，浮点数的存储格式、运算结果就完全一致。这是 JS 能在不同浏览器运行、C 程序能跨平台编译的关键基础。

2. 硬件级性能加持：现代 CPU 的浮点运算单元（FPU）、GPU 计算核心都是直接按 IEEE 754 设计的，能硬件级加速浮点数运算。如果不用 IEEE 754，就得用纯软件模拟其他浮点数规则，运算速度会慢几十倍甚至上百倍（比如早期无 FPU 的处理器，软件模拟浮点数运算卡顿明显）。

3. 兼顾精度与存储效率：64 位双精度（double）用 8 字节就能存储约 16 位有效数字，能覆盖绝大多数日常场景（前端布局计算、后端普通数值处理、科学计算入门场景）。对比其他方案（如十进制浮点数），它在“存储占用”和“精度范围”之间取得了最优平衡。

3.2 有精度问题为啥还留着？—— 问题是“局部的”，替代成本太高

IEEE 754 的精度问题（如 0.1+0.2≠0.3）并非“致命缺陷”，而是「二进制浮点数的天然特性」——本质是“十进制小数转二进制时的无限循环”导致的，不是标准设计的漏洞。它之所以能保留至今，核心是“问题场景有限，替代方案代价太大”：

1. 精度问题只影响“特定场景”：只有“十进制无限循环小数”（如 0.1、0.2、0.3）和“超过 53 位的大整数”会出现精度问题；而绝大多数场景（如整数运算、10.5 这类能被二进制精确表示的小数）完全不受影响。日常开发中，只要不是金融级小数计算、超大整数处理，这些误差几乎可以忽略（比如页面显示 0.3，低精度打印时误差会被自动掩盖）。

2. 替代方案的成本远高于收益：能解决二进制浮点数误差的方案（如十进制浮点数标准、任意精度库）都有明显短板：① 十进制浮点数（如 IEEE 754-2008 新增的 decimal64）硬件支持少，大部分 CPU 不原生支持，运算速度慢；② 任意精度库（如 JS 的 decimal.js、C 的 GMP）是纯软件模拟，性能远低于硬件加速，且需要额外引入库，增加开发复杂度。

3. 历史惯性与生态依赖：自 1985 年以来，全球无数软件、硬件、编程语言都基于 IEEE 754 构建。如果淘汰它，所有现有程序（如操作系统内核、数据库、浏览器引擎）都要重构，所有 CPU 都要重新设计，这个成本是整个行业无法承受的。反而，针对少数高精度场景（如金融），用“转整数计算”“专业库”等补丁方案，比淘汰标准更现实。

简单说：IEEE 754 的“不完美”是“可接受的局部问题”，而它带来的“一致性、高性能、兼容性”是整个计算机生态的基石。保留它，远比替换它更划算。

贡献者: gritwang

上一页前端实现自定义范围拍摄

下一页JS的转换规则