JS计算0.1+0.2!=0.3的原因

今天遇到一个特别的问题，小数0.1+0.2不等于0.3；而是等于：

09_13_33__04_10_2019.jpg

怎么解决那？

方法一

最简单的就是先把0.1和0.2换成别的数字（因为在js中只有这两个数相加有bug，例如：1.1+1.2不会有问题），所以先让0.1和0.2分别乘以10，求和之后再除以10 ，则不会有问题：

(0.1*10+0.2*10)/10 ===0.3

方法二

可能很多小伙伴都忘记了js的Number对象有一个保留小数位数的方法：toFixed()；传入一个需要保留的位数就OK：

parseFloat((0.1+0.2).toFixed(10)) ===0.3

因为toFixed方法返回的是一个字符串，所以别忘了把字符串转回浮点数

为什么会出现这种原因那？

计算机内部如何表示数
我们都知道，计算机用位来储存及处理数据。每一个二进制数（二进制串）都一一对应一个十进制数。

1. 计算机内部如何表示整数

这里以十进制数13来展示“按位计数法”如何表示整数：

十进制值 进制 按位格式 描述
13 10 13 1x10^1 + 3x10^0 = 10 + 3
13 2 1101 1x2^3 + 1x2^2 + 0x2^1 + 1x2^0 = 8 + 4 + 0 + 1

2. 计算机内部如何表示小数
   再看小数怎么用按位计数法表示，以十进制数0.625为例：

十进制值 进制 按位格式 描述
0.625 10 0.625 6x10^-1 + 2x10^-2 + 5x10^-3 = 0.6 + 0.02 + 0.005
0.625 2 0.101 1x2^-1 + 0 x2^-2 + 1x2^-3 = 1/2 + 0 + 1/8

3. 如何用二进制表示0.1
   关于十进制与二进制间如何转换，这里不细说，直接给出结论：

十进制整数转二进制方法：除2取余；十进制小数转二进制方法：乘2除整

十进制0.1转换成二进制，乘2取整过程：

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

从上面可以看出，0.1的二进制格式是：0.0001100011....。这是一个二进制无限循环小数，但计算机内存有限，我们不能用储存所有的小数位数。那么在精度与内存间如何取舍呢？

答案是：在某个精度点直接舍弃。当然，代价就是，0.1在计算机内部根本就不是精确的0.1，而是一个有舍入误差的0.1。当代码被编译或解释后，0.1已经被四舍五入成一个与之很接近的计算机内部数字，以至于计算还没开始，一个很小的舍入错误就已经产生了。这也就是 0.1 + 0.2 不等于0.3 的原因。

有误差的两个数，其计算的结果，当然就很可能与我们期望的不一样了。注意前面的这句话中的“很可能”这三个字？为啥是很可能昵？

0.1 + 0.1 为什么等于0.2
答案是：两个有舍入误差的值在求和时，相互抵消了，但这种“负负得正，相互抵消”不一定是可靠的，当这两个数字是用不同长度数位来表示的浮点数时，舍入误差可能不会相互抵消。

又如，对于 0.1 + 0.3 ，结果其实并不是0.4，但0.4是最接近真实结果的数，比其它任何浮点数都更接近。许多语言也就直接显示结果为0.4了，而不展示一个浮点数的真实结果了。

另外要注意，二进制能精确地表示位数有限且分母是2的倍数的小数，比如0.5，0.5在计算机内部就没有舍入误差。所以0.5 + 0.5 === 1

计算机这样胡乱舍入，能满足所有的计算需求吗
我们看两个现实的场景：

对于一个修建铁路的工程师而言，10米宽，还是10.0001米宽并没有什么不同。铁路工程师就不需要这么高0.x这样的精度
对于芯片设计师，0.0001米就会是一个巨大不同，他也永远不用处理超过0.1米距离
不同行业，要求的精度不是线性的，我们允许（对结果无关紧要的）误差存在。10.0001与10.001在铁路工程师看来都是合格的。

虽然允许误差存在，但程序员在使用浮点数进行计算或逻辑处理时，不注意，就可能出问题。记住，永远不要直接比较两个浮点的大小：

var a = 0.1
var b = 0.2

if (a + b === 0.3) {
  // doSomething
}