JS浮点数精度丢失问题

由于计算机的二进制实现和位数限制，有些数无法有限表示。就像一些无理数不能有限表示，如 圆周率 3.1415926...，1.3333... 等。JS 遵循 IEEE 754 规范，采用双精度存储（double precision），占用 64 bit。

(1位用来表示符号位，11位用来表示指数，52位表示尾数）

由于无论是采用了哪种表达方式进行怎样的计算，到了计算机的最底层，都是通过1和0的机器码来对具体的数据和操作进行具体的实现。由于底层实现机制的原因，浮点数在转换为二进制表示的时候，无法精确表示这种包含小数点的数据，其本质是将浮点数转换成了用二进制表示的最接近的近似值。下面一个例子可以用来简单说明浮点数在转换为二进制时候的计算方法。如下图：

0.02625=0.000001101（二进制），无法精确求出二进制表示，因此采用“四舍五入法”（逢1进，逢0舍）。

以上就是问题产生的原理，很多编译型语言如Java,c#等都对浮点数的处理进行了封装。因此平时大多数情况下，并不会出现明显的可见的问题。js本身作为解释性语言，好像这点上有着天生的劣势。

浮点数，比如

0.1 >> 0.0001 1001 1001 1001…（1001无限循环）
0.2 >> 0.0011 0011 0011 0011…（0011无限循环）

此时只能模仿十进制进行四舍五入了，但是二进制只有 0 和 1 两个，于是变为 0 舍 1 入。这即是计算机中部分浮点数运算时出现误差，丢失精度的根本原因。

大整数的精度丢失和浮点数本质上是一样的，尾数位最大是 52 位，因此 JS 中能精准表示的最大整数是 Math.pow(2, 53)，十进制即 9007199254740992。                                                                                                                                                              大于 9007199254740992 的可能会丢失精度

9007199254740992     >> 10000000000000...000 // 共计 53 个 0
9007199254740992 + 1 >> 10000000000000...001 // 中间 52 个 0
9007199254740992 + 2 >> 10000000000000...010 // 中间 51 个 0
9007199254740992 + 1 // 丢失        //9007199254740992 
9007199254740992 + 2 // 未丢失      //9007199254740994   
9007199254740992 + 3 // 丢失        //9007199254740992 
9007199254740992 + 4 // 未丢失      //9007199254740996   

JS数字精度丢失的一些典型问题

1. 两个简单的浮点数相加

	
0.1 + 0.2 != 0.3 // true

2. 大整数运算

9999999999999999 == 10000000000000001 // true

3. toFixed 不会四舍五入（Chrome）

1.335.toFixed(2) // 1.33

解决方案：

对于整数，前端出现问题的几率可能比较低，毕竟很少有业务需要需要用到超大整数，只要运算结果不超过 Math.pow(2, 53) 就不会丢失精度。

对于小数，前端出现问题的几率还是很多的，尤其在一些电商网站涉及到金额等数据。解决方式：把小数放到位整数（乘倍数），再缩小回原来倍数（除倍数）

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

toFixed的修复如下

// toFixed 修复
function toFixed(num, s) {
    var times = Math.pow(10, s)
    var des = num * times + 0.5
    des = parseInt(des, 10) / times
    return des + ''
}