JavaScript浮点数精度问题

引言：

console.log(0.1 + 0.2); // 0.30000000000000004

浮点数精度常见问题

在 JavaScript 中整数和浮点数都属于 number 数据类型，所有数字都是以64 位浮点数形式储存，即便整数也是如此。 所以我们在打印 1.00 这样的浮点数的结果是 1 而非 1.00 。

场景一：进行浮点值运算结果的判断

// 加法
console.log(0.1 + 0.2); // 0.30000000000000004
console.log(0.7 + 0.1); // 0.7999999999999999
console.log(0.2 + 0.4); // 0.6000000000000001
console.log(2.22 + 0.1); // 2.3200000000000003

// 减法
console.log(1.5 - 1.2); // 0.30000000000000004
console.log(0.3 - 0.2); // 0.09999999999999998

// 乘法
console.log(19.9 * 100); // 1989.9999999999998
console.log(19.9 * 10 * 10); // 1990
console.log(9.7 * 100); // 969.9999999999999
console.log(39.7 * 100); // 3970.0000000000005

// 除法
console.log(0.3 / 0.1); // 2.9999999999999996
console.log(0.69 / 10); // 0.06899999999999999

场景二：将小数乘以 10 的 n 次方取整
比如将钱币的单位，从元转化成分，经常写出来的是 parseInt(yuan*100, 10)

console.log(parseInt(0.58 * 100, 10)); // 57

场景三：四舍五入保留 n 位小数
例如我们会写出 (number).toFixed(2)，但是看下面的例子：

console.log((1.335).toFixed(2)); // 1.33

在上面的例子中，我们得出的结果是 1.33，而不是预期结果 1.34。

为什么会有这样的精度丢失的问题？

计算机底层只有 0 和 1， 所以所有的运算最后实际上都是二进制运算。

十进制整数利用辗转相除的方法可以准确地转换为二进制数，但浮点数却不能

JavaScript 里的数字是采用 IEEE 754 标准的 64 位双精度浮点数。

该规范定义了浮点数的格式，对于 64 位的浮点数在内存中的表示，最高的 1 位是符号位，接着的 11 位是指数，剩下的 52 位为有效数字，具体如下：

符号位 S：第 1 位是正负数符号位（sign），0 代表正数，1 代表负数
指数位 E：中间的 11 位存储指数（exponent），用来表示次方数
尾数位 M：最后的 52 位是尾数（mantissa），储存小数部分，超出的部分自动进一舍零
也就是说，浮点数最终在运算的时候实际上是一个符合该标准的二进制数

符号位决定了一个数的正负，指数部分决定了数值的大小，小数部分决定了数值的精度。
既然限定位数，必然有截断的可能。

我们可以看一个例子：

console.log(0.1 + 0.2); // 0.30000000000000004

为了验证该例子，我们得先知道怎么将浮点数转换为二进制，整数我们可以用除 2 取余的方式，小数我们则可以用乘 2 取整的方式。

0.1 转换为二进制：

0.1 * 2，值为 0.2，小数部分 0.2，整数部分 0

0.2 * 2，值为 0.4，小数部分 0.4，整数部分 0

0.4 * 2，值为0.8，小数部分0.8，整数部分0

0.8 * 2，值为 1.6，小数部分 0.6，整数部分 1

0.6 * 2，值为 1.2，小数部分 0.2，整数部分 1

0.2 * 2，值为 0.4，小数部分 0.4，整数部分 0

从 0.2 开始循环

0.2 转换为二进制可以直接参考上述，肯定最后也是一个循环的情况

所以最终我们能得到两个循环的二进制数：

0.1：0.0001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1100 …

0.2：0.0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 …

这两个的和的二进制就是：

sum：0.0100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 …

最终我们只能得到和的近似值（按照 IEEE 754 标准保留 52 位，按 0 舍 1 入来取值），然后转换为十进制数变成：

sum ≈ 0.30000000000000004

再例如

console.log((1.335).toFixed(2)); // 1.33

因为 1.335 其实是 1.33499999999999996447286321199，toFixed 虽然是四舍五入，但是是对 1.33499999999999996447286321199 进行四五入，所以得出 1.33。

在 Javascript 中，整数精度同样存在问题，先来看看问题：

console.log(19571992547450991); // 19571992547450990
console.log(19571992547450991===19571992547450992); // true

同样的原因，在 JavaScript 中 number 类型统一按浮点数处理，整数是按最大 54 位来算，

最大( 253 - 1，Number.MAX_SAFE_INTEGER、9007199254740991)
最小( -(253 - 1)，Number.MIN_SAFE_INTEGER、-9007199254740991)
所以只要超过这个范围，就会存在被舍去的精度问题。

当然这个问题并不只是在 Javascript 中才会出现，几乎所有的编程语言都采用了 IEEE-754 浮点数表示法，任何使用二进制浮点数的编程语言都会有这个问题。

只不过在很多其他语言中已经封装好了方法来避免精度的问题，而 JavaScript 是一门弱类型的语言，从设计思想上就没有对浮点数有个严格的数据类型，所以精度误差的问题就显得格外突出。

通常这种对精度要求高的计算都应该交给后端去计算和存储，因为后端有成熟的库来解决这种计算问题。

那在JavaScript中怎么解决这种问题呢

有几个不错的类库

Math.js

Math.js 是专门为 JavaScript 和 Node.js 提供的一个广泛的数学库。它具有灵活的表达式解析器，支持符号计算，配有大量内置函数和常量，并提供集成解决方案来处理不同的数据类型。

像数字，大数字（超出安全数的数字），复数，分数，单位和矩阵。 功能强大，易于使用。

decimal.js

为 JavaScript 提供十进制类型的任意精度数值。

big.js

不仅能够支持处理 Long 类型的数据，也能够准确的处理小数的运算。

---

来自渡一教育谢老师备课文案----浮点数精度问题