前端面试里最“阴魂不散”的题之一：

```js
0.1 + 0.2 === 0.3 // false
0.1 + 0.2         // 0.30000000000000004
```

很多人把它当成“JavaScript 的 bug”，但它其实是**浏览器 JS 引擎在按规范、按硬件浮点规则认真做事**的结果。

---

## 1）关键前提：JS 里的 Number 不是“十进制小数”，而是 IEEE 754 双精度浮点数

JavaScript 的 `Number` 类型本质上是 **IEEE 754 的 64-bit double（双精度二进制浮点数）**，由符号位、指数位、尾数位组成，能提供大约 15~17 位十进制有效精度。([MDN Web Docs][1])

这意味着：**它能精确表示的值是离散的、以 2 的幂为刻度的一批数**。像 `0.125 (= 1/8)` 这种用二进制能有限表示的分数没问题；但 `0.1 (= 1/10)` 在二进制里是**无限循环小数**，天生就装不进有限位数的二进制浮点。

Python 官方教程讲这点非常直白：`1/10` 不能被二进制分数精确表示，机器只能把输入的 `0.1` 转成最接近的 `J / 2**N`。([Python documentation][2])

---

## 2）第一处“精度损失”：字面量 `0.1` 进 JS 引擎时就已经被“就近取值”了

你在源码里写：

```js
const x = 0.1
```

你以为它是数学上的 0.1，但 JS 引擎会把你写的十进制字面量**解析成最接近的可表示 double**。

文档里给了一个“把真相写全”的版本：`0.1` 实际对应的 double，展开成十进制是：

```
0.1000000000000000055511151231257827021181583404541015625
```

同理：

* `0.2` 更接近的是
  `0.200000000000000011102230246251565404236316680908203125`
* `0.3` 更接近的是
  `0.299999999999999988897769753748434595763683319091796875`

所以从一开始，`0.1`、`0.2`、`0.3` 在机器内部就不是“你看到的那串十进制字符”。

---

## 3）第二处“精度损失”：做加法时，结果也未必刚好落在可表示的点上

当你写：

```js
const sum = 0.1 + 0.2
```

引擎做的其实是（以文档给的精确十进制展开来理解）：

```
0.10000000000000000555...
+
0.20000000000000001110...
=
0.30000000000000001665...
```

但这个精确结果**依然不是一个可精确表示的 double**，于是又要再做一次“就近取值”，最终落在：

```
0.3000000000000000444089209850062616169452667236328125
```

也就是说：你看到的 `0.30000000000000004`，背后是两次“逼近”叠加的产物：

* 输入时逼近一次
* 运算后逼近一次

---

## 4）第三处“精度损失”：为什么控制台会打印出这么“刺眼”的 `...00004`？

这里很关键：**控制台/`toString()` 并不会把一个 Number 的所有十进制位“完整吐出来”**。规范的目标更像是：

> 输出一串十进制字符，让它足以把这个 Number 跟附近的其他 Number 区分开，并且能“往返不丢”（round-trip）。

规范里也明确提到：`toString` 只打印“足够区分相邻 Number 值的有效数字”；甚至举例说明 `toFixed` 有时会比 `toString` 更“精确地打印”。([TC39][3])

而很多引擎在实现层面会使用“最短唯一十进制表示”的转换策略（例如相关代码里就能看到 `SHORTEST` 这种模式）。([Chromium Git Repositories][4])

于是现象就变得非常合理了：

* `0.1` 内部其实是 `0.10000000000000000555...`
  但打印 `0.1` 已经足够唯一标识它，所以控制台显示 `0.1`
* `0.3` 内部其实是 `0.29999999999999998889...`
  但打印 `0.3` 也足够唯一标识它，所以控制台显示 `0.3`
* `0.1 + 0.2` 内部落在 `0.30000000000000004440...`
  这时打印 `0.3` **已经不足以唯一标识**这个值了，于是就需要更多一位（或几位）数字，最终你看到：
  `0.30000000000000004`

---

## 5）用一段“前端自测”代码把误差直接暴露出来

你不需要什么神秘库，直接用 `toPrecision(17)`（17 位基本覆盖 double 的有效十进制精度）：

```js
(0.1).toPrecision(17)        // "0.10000000000000001"
(0.2).toPrecision(17)        // "0.20000000000000001"
(0.3).toPrecision(17)        // "0.29999999999999999"
(0.1 + 0.2).toPrecision(17)  // "0.30000000000000004"
```

---

## 6）这不是 JS 独有：只要用 double 的语言都会遇到

只要某门语言用的是 IEEE 754 binary64（double），就会遇到同类现象。Python 文档专门用 `0.1` 做了科普案例。([Python documentation][2])
而 JS 的 `Number` 类型本身就被定义为这种双精度格式。([MDN Web Docs][1])

---

## 7）工程里怎么处理：别跟浮点“硬刚”，换策略

### 金额/计数：用整数当最小单位

比如分/厘/毫，统一用整数存储、运算，展示时再格式化。

### 比较：用“误差阈值”而不是 `===`

`Number.EPSILON` 常用来做近似比较的基准（它描述了 1 与最接近的大于 1 的可表示数之间的差）。([MDN Web Docs][5])

```js
function nearlyEqual(a, b, eps = Number.EPSILON) {
  return Math.abs(a - b) < eps;
}

nearlyEqual(0.1 + 0.2, 0.3) // true
```

> 真实项目里常用更稳的版本：`eps * Math.max(1, |a|, |b|)`，避免数值尺度变大后阈值过小。

### 需要“十进制精确运算”：用十进制库，或关注 Decimal 提案

JS 社区一直在推进内建十进制类型的提案（`Decimal`），目前仍在演进中。([TC39][6])
在它落地前，像 `decimal.js` / `big.js` 这类库仍是主力选择。

---

## 结尾：把它当成“浏览器内核常识”，你就不怕它了

`0.1 + 0.2` 之所以变成 `0.30000000000000004`，不是因为 JS “算错了”，而是因为：

1. **十进制字面量解析进 double 时就会逼近一次**
2. **double 运算结果再逼近一次**
3. **输出为字符串时按“最短可区分表示”规则再做一次取舍**([TC39][3])

理解了这三步，你就会发现：这题一点也不玄学，它只是浮点世界的日常。

如果你愿意，我也可以把这三步分别对应到 V8/SpiderMonkey/JavaScriptCore 在“解析数字字面量 → JIT/解释执行 → number-to-string”的典型实现路径上，结合浏览器调试手段（DevTools、Memory/Performance、反汇编/IR）再展开讲一版。

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number "Number - JavaScript | MDN"
[2]: https://docs.python.org/3/tutorial/floatingpoint.html?utm_source=chatgpt.com "15. Floating-Point Arithmetic: Issues and Limitations"
[3]: https://tc39.es/ecma262/multipage/numbers-and-dates.html "ECMAScript® 2026 Language Specification"
[4]: https://chromium.googlesource.com/external/github.com/dart-lang/sdk/%2B/refs/tags/3.3.0-199.0.dev/third_party/double-conversion/src/double-to-string.cc?utm_source=chatgpt.com "third_party/double-conversion/src/double-to-string.cc"
[5]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/EPSILON?utm_source=chatgpt.com "Number.EPSILON - JavaScript - MDN Web Docs"
[6]: https://tc39.es/proposal-decimal/?utm_source=chatgpt.com "Decimal"


很多人把它当成“JavaScript 的 bug”，但它其实是浏览器 JS 引擎在按规范、按硬件浮点规则认真做事的结果。

为什么 0.1 + 0.2 会得到 0.30000000000000004

紫薇堂堂主

编程语言

前端

算法

JavaScript中0.1+0.2≠0.3的原因在于IEEE754双精度浮点数规范。JS引擎将十进制数转换为二进制时会产生精度损失，运算时再次近似处理，最终输出最短可区分表示。这不是JS独有问题，建议使用整数运算或误差阈值比较来处理精度问题。

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

为什么 0.1 + 0.2 会得到 0.30000000000000004-腾讯云开发者社区-腾讯云

为什么 0.1 + 0.2 会得到 0.30000000000000004

为什么 0.1 + 0.2 会得到 0.30000000000000004

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐