preview和response的值不一样

前段时间在开发的过程中遇到一个奇怪的 Bug。
在服务端数据正常,前端页面渲染代码正常的情况下,浏览器页面渲染出的内容却不一样。
经过一番定位,最终在 Chrome 浏览器的控制台找到了线索。
在控制台里面查看到的情形是 response 和 preview 的值不一样

一、问题表现

preview 的结果截图
preview

response 的结果截图
response

这就奇怪了,理论上来说 preview 和 response 都是同一份数据,怎么可能不一样呢?
然而事实就是如此。

1
2
preview  返回 817809136971941000
response 返回 817809136971940993

于是,我通过 postman 发起请求,返回的数据和 response 的值一致。
后又将两个返回值和数据库里面的数据做了比对,同样发现 response 的值和后端数据库存储的是一样的。
也就是说 response 的值是对的,preview 的值是错的。

二、找到了原因并解决问题

经过网上搜索、讨论、以及各种测试,最终发现了问题的原因。

直接原因就是:后端对接口做了改造,将原本返回的 string 类型的 ID 改为了 Long 类型。

根本原因是:JavaScript 中 Number 类型在处理 Long 型的数值的时候,超过了一定限制之后就会出现精度丢失的情况。

前面的 preview 和 response 不一致的问题就是因为 preview 在显示的时候处理 response 的 Long类型的时候触发了精度丢失。

可以在浏览器控制台验证一下:
比较验证
可以看出,变量 b 在输出的时候值变了,xx40993变为了xx41000

继续在控制台验证,输出更多 Long 类型数字的情形:

1
2
3
4
5
817809136971940993 => 817809136971941000 // 18 位
81780913697194099 => 81780913697194100 // 17 位
81780913697194041 => 81780913697194050 // 17 位,第16位 +1 了
81780913697194031 => 81780913697194030 // 17 位,第16位未 +1。
8178091369719409 => 8178091369719409 // 16 位,正常

可以看出,直接在控制台执行 Long 数值的时候,其执行结果千奇百怪。
其根本原因就是因为数字太长所以触发了 JS 数值类型的精度问题。

所以解决办法也很简单:让后端将其返回的 number 类型转换为 string 即可。

那么 Javascript 为什么会出现 Long 类型数值的精度问题呢?

三、Javascript 数值存储

Javascript 采用的是双精度浮点数存储的,每个数字占 8 个字节,即 64 个bit。
所以,JavaScript 中数值类型的精度是有限的,内部只有一种数字类型 Number。
所有数字都是采用 IEEE 754 标准定义的双精度 64 位格式存储,即使整数也是如此。
这就是说,JavaScript 语言实际上并没有真正的整数,所有数值都是小数(64 位浮点数)。

64位格式
上图所示即为双精度浮点数的存储方式,途中划分了存储位,64 位格式存储其实际存储小数的有 52 位。

1
2
3
4
5
第 [63]     位 sign 表示符号位,1 bit,0 表示正数,1 表示负数。
第 [62~52] 位 exponent 表示指数位,11 bits,最大值为 11个1,即 Math.pow(2, 11)-1,即(0 ~ 2047)
第 [51~0] 位 fraction 表示具体小数位,从上图可以看出其存储位是 52位,即 52 bits,最大值为 52 个1。
然而,其实际还有一位是非显式存储的,因为二进制表示有效数字总是 1xxx 的形式,为数部分在规约形式下第一位默认为1,给省略了。
因此,其实际可以有 52 + 1 位来存储,即 Math.pow(2, 53)-1,即(9007199254740991)

能够通过 53 位小数位一一对应存储的数我们将其称为安全数字。
javascript 提供了查询安全数字的方法。

1
2
console.log(Number.MAX_SAFE_INTEGER); //  9007199254740991 (Math.pow(2, 53) - 1)
console.log(Number.MIN_SAFE_INTEGER); // -9007199254740991

在实际程序运行过程中,如果有数字超过了这个安全数字范围,则就会出现计算不准确的问题。
前面的 817809136971940993 有长度达到了17,很显然大于了 9007199254740991,因此出现计算错误(精度丢失)也就能理解了。

四、0.1+0.2问题

javascript 数值计算有一个很经典的问题,0.1+0.2 === 0.30000000000000004,其底层原因就是前面的双精度浮点数存储导致的。

计算过程如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Number(0.1).toString(2) 0.1 转换为二进制
0.0001100110011001100110011001100110011001100110011001100110011
// 从第一个1开始,向后保留52位尾数,(1入0舍)
0.0001100110011001100110011001100110011001100110011001101

// Number(0.2).toString(2) 0.2 转换为二进制
// 转二进制
0.001100110011001100110011001100110011001100110011001100110011
// 从第一个1开始,向后保留52位尾数,(1入0舍)
0.001100110011001100110011001100110011001100110011001101

// 进行相加
0.0001100110011001100110011001100110011001100110011001101
+
0.001100110011001100110011001100110011001100110011001101
=
// 相加后的结果
0.0100110011001100110011001100110011001100110011001100111
// 从第一个1开始,向后保留52位尾数,(1入0舍)
0.01001100110011001100110011001100110011001100110011010
// 转十进制
0.30000000000000004

通过上面一步一步计算可以看出,之所以0.1+0.2 === 0.30000000000000004有三个原因:

1
2
3
1)javascript 的数值计算是将数字转换为二进制进行计算的。
2)0.1 和 0.2 转换为二进制之后陷入了无限循环。
3)javascript 的数值存储是有精度限制的,即最多52位有效小数,1入0舍,对0.1和0.2分别进行了数值取舍。

经过一番精度截取之后再计算就导致了 0.1+0.2 != 0.3 了。

五、总结

精度丢失的根本问题就在于 Javascript 语言本身的数值类型采用的是“双精度浮点数”。
而“双精度浮点数”本身存储位只有 64 位,除去符号位、指数位之后就只剩下 52 位,再加上 1 位非显式存储位,总共 53 位。
即小数后面最多可以有52个1,最大值为 Math.pow(2, 53)-1,超过这个值就没法存了,只能丢弃,也就是所谓的“精度丢失”。
超过 2^53-1 之后的数被称为不安全的数,因为此后只要指数相同,并且尾数前 52 位相同,则这个两个数数值相同(因为 52位之后的数被丢弃了)。

相关链接

维基百科-双精度浮点数
0.1+0.2问题