JS位运算异常（位运算精度丢失）的原因探究
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JS位运算异常（位运算精度丢失）的原因探究相关的知识，希望对你有一定的参考价值。
参考技术A 《【转+补充】深入研究js中的位运算及用法》
《【JS时间戳】获取时间戳的最快方式探究》
日常开发中一直没遇到过位运算导致精度丢失的问题，直到这天，搞10位时间戳取整的时候，终于被我撞上了。具体是个什么场景呢，我们来还原下案发现场：
可以看到输出的结果为：
得到的 t 是一个精确到微秒的时间戳。但是请求接口的时候需要的是一个10位（精确到秒）的时间戳，所以这里需要将它转换为10位，自然就是 ➗1000 即可，然后通过位运算来实现类似 Math.trunc 的取证效果，得到了我们要的10位时间戳。至此完美解决！那问题又是如何发生的呢？
按照上面的运算规律，如果我们要获取13位时间戳，是不是直接对 t>>0 就可以了呢？我们来看一下：
输出结果如下：
WTF!!!看到了咩！！！居然输出了一个负数！！！我们想要的结果应该是 1597113682985 才对啊！为什么会出现了负数呢！！！
由此，怪物出现啦！我们今天就来解读（xiang fu)一下它！
想到这里，我们一定就会怪是位运算的锅！那这个锅该怎么让位运算背起来呢！我们来研究一下！
首先我们知道，JS中没有真正的整型，数据都是以double(64bit)的标准格式存储的，这里就不再赘述了，要想搞透其中的原理，请打开 【传送门】
位运算是在数字底层（即表示数字的 32 个数位）进行运算的。由于位运算是低级的运算操作，所以速度往往也是最快的（相对其它运算如加减乘除来说），并且借助位运算有时我们还能实现更简单的程序逻辑,缺点是很不直观，许多场合不能够使用。
以下来源于w3shool:
ECMAScript 整数有两种类型，即有符号整数（允许用正数和负数）和无符号整数（只允许用正数）。 在 ECMAScript 中，所有整数字面量默认都是有符号整数 ，这意味着什么呢？
有符号整数使用 31 位表示整数的数值，用第 32 位表示整数的符号，0 表示正数，1 表示负数。数值范围从 -2147483648 到 2147483647 。
可以以两种不同的方式存储二进制形式的有符号整数，一种用于存储正数，一种用于存储负数。 正数是以真二进制形式存储的 ，前 31 位中的每一位都表示 2 的幂，从第 1 位（位 0）开始，表示 20，第 2 位（位 1）表示 21。没用到的位用 0 填充，即忽略不计。例如，下图展示的是数 18 的表示法。
那在js中二进制和十进制如何转换呢？如下
负数同样以二进制存储，但使用的格式是二进制补码。计算一个数值的二进制补码，需要经过下列3个步骤：
例如，要确定-18的二进制表示，首先必须得到18的二进制表示，如下所示：
0000 0000 0000 0000 0000 0000 0001 0010
接下来，计算二进制反码，如下所示：
1111 1111 1111 1111 1111 1111 1110 1101
最后，在二进制反码上加 1，如下所示：
1111 1111 1111 1111 1111 1111 1110 1101 +
0000000000000000000000000000 0001 =
1111 1111 1111 1111 1111 1111 1110 1110
因此，-18 的二进制就是 1111 1111 1111 1111 1111 1111 1110 1110
而其相反数18的二进制为 0000 0000 0000 0000 0000 0000 0001 0010
ECMAScript会尽力向我们隐藏所有这些信息，在以二进制字符串形式输出一个负数时，我们看到的只是这个负数绝对值的二进制码前面加上了一个负号
javascript 只有一种数字类型 ( Number )
我们将 1596596596.3742654.toString(2) 转为二进制字符串表示如下：
1011111001010100010000101110100.0101111111001111110111
但实际在内存中的存储如下：
说到这里就不得不简单提一下数字精度丢失的问题。上面也知道，JS中所有的数字都是用double方式进行存储的，所以必然会存在精度丢失问题。
以下转自文章： JavaScript数字精度丢失问题总结
此时只能模仿十进制进行四舍五入了，但是二进制只有 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 + 2 ``// 未丢失
9007199254740992 + 3 ``// 丢失
9007199254740992 + 4 ``// 未丢失
以上，可以知道看似有穷的数字, 在计算机的二进制表示里却是无穷的，由于存储位数限制因此存在“舍去”，精度丢失就发生了。
想了解更深入的分析可以看这篇论文（你品！你细品！）： What Every Computer Scientist Should Know About Floating-Point Arithmetic
关于精度和范围的内容可查看 【JS的数值精度和数值范围】
通过前面的知识补充，我们已经知道：
这也就是为什么对于整数部位为10位的时间戳，通过位运算可以进行取整（因为目前时间戳159xxxxxxx<2147483647），不存在时间戳超过范围的问题。但是对于13位时间戳，如 1596615447123>2147483647 ，此时再通过位运算操作的时候就会导致异常，如：
这主要是因为在进行位运算之前，JS会先将64bit的浮点数 1596615447015.01 转为32bit的有符号整型后进行运算的，这个转换过程如下：
为了验证上述过程，我们再举一个例子： 1590015447015.123 >> 0 = 877547495
将将将将！没错的吧！所以JS的这个坑还真是。。。 让人Orz
js 中Math.round()精度问题？急
在下面的代码中，如果输入7位（0.0000007）及7位以上的（0.00000008）小数（即小数最后一位不是0其它位数都是0）时，返回的值就会变成科学计数法，请教这是个什么问题？该怎么解决 ？谢谢！ <script type="text/javascript"> function _round() var v =document.getElementById("testValue").value ; var splitStr = v.split("."); var xs = splitStr[1]; var e = -1 ; if(e == -1) if(xs!=null) e = xs.length; else e = 0; var t = 1; for (; e > 0; t *= 10, e--); for (; e < 0; t /= 10, e++); var finalValue = Math.round(v * t) / t ; alert(finalValue) ; ; </script> </head> <body> <input type="text" id="testValue" value=""> <input type="button" value="测试" onClick="_round()"> </body>
参考技术A 不是BUG，最简单的alert(0.56*100);。JavaScript小数在做四则运算时，精度会丢失。具体可参考IEEE
754的浮点计数法
以上是关于JS位运算异常（位运算精度丢失）的原因探究的主要内容，如果未能解决你的问题，请参考以下文章