至于为什么JavaScript会有精度问题呢，可以看 这里 。简单来说就是因为： JavaScript中所有的数字（包括整数和小数）都只有一种类型–Number。它的实现遵循IEEE 754标准，使用64位固定长度来表示，也就是标准的double双精度浮点数。它的优点是可以归一化处理整数和小数，节省储存空间。而实际计算的时候会转换成二进制计算再转成十进制。进制转换之后会很长，舍去一部分，计算再转回来，就有了精度误差。
BigNumber.js是一个用于任意精度计算的js库。可以在 官方文档 的console中测试使用。也可以通过npm install bignumber.js --save来安装。然后 import BigNumber from 'bignumber.js' 来引入使用。他的大概原理是将所有数字当做字符串，重新实现了计算逻辑。缺点是性能比原生的差很多。
现在 TC39 已经有一个 Stage 3 的提案 proposal bigint，大数问题有望彻底解决。在浏览器正式支持前，可以使用 Babel 7.0 来实现，它的内部是自动转换成 big-integer 来计算，要注意的是这样能保持精度但运算效率会降低。
具体用法可以参考以下资料：
官方文档
bignumber.js使用记录
BigNumber 讲解
就不再敖述了，下边随便写点常用的方法：
// 转为 bignumberconstx=newBigNumber('123456789.123456789')// 转为 普通数字x.toNumber()// 格式化(小数点)x.toFormat()// '123,456,789.123456789'x.toFormat(3)// '123,456,789.123'// 计算x.plus(0.1)// 加法x.minus(0.1)// 减法x.times(0.1)// 乘法x.div(0.1)// 除法x.mod(3)// 取模/取余// 比较大小x.eq(y)// isEqualTo 的简写，是否相等x.gt(y)// isGreaterThan 的简写，是否大于x.gte(y)// isGreaterThanOrEqualTo 的简写，是否大于等于x.lt(y)// isLessThan 的简写，是否小于x.lte(y)// isLessThanOrEqualTo 的简写，是否小于等于// 取非，改变数字的正负号x.negated()
如：0.1+0.2 !== 0.3；0.1*0.2 !== 0.03
如：9999999999999999 === 10000000000000001
如：1.335.toFixed(2) // 1.33；1.336.toFixed(2) // 1.34
二进制模仿十进制进行四舍五入，而二进制只有0和1，于是就0舍1入，于是就导致了小数计算不精确。大数的精度丢失本质上是和小数一样，js中表示最大的数是Math.pow(2, 53),十进制即 9007199254740992；大于该数的值可能会丢失精度。
小数的话，一般转成整数进行计算，然后对结果做除法；同样也可以直接对结果进行4舍5入；
对于大数出现的问题概率较低，毕竟还要运算结果不超过最大数就不会丢失精度；
javaScript数字精度丢失问题总结
js中精度问题以及解决方案
JavaScript 中精度问题以及解决方案
数组的索引按照32位且无符号定点整数存储，也就是说数组索引最大值为 2 32 ，而数组以0开始，所以实际最大值为2 32 - 1
对于 & | ^ ~ 以后单独再说,主要说明 <<, >>, >>>
ECMA相关位运算说明
完整的位运算步骤
js能精确计算（运算结果）的数值范围是 [-2 53 , +2 53 ]
js能表示的纯整数数值范围是 [-1.8x10 308 , +1.8x10 308 ]
js能表示的纯小数数值范围是 [ -5x10 -324 , -1) ∪ (+1, 5x10 -324 ]
IEE754标准就和js中的正则表达式，unicode编码一样，他不是js特有的东西的，而是一种国际上通用规范，
目的其一，方便；
目的二，使程序可移植性强。
（在js中定义的数值，解释器会帮我们把值转化为IEEE754标准的64位浮点型，如果是位运算，解释器会把值定义为32位整型）
了解他之前，先看一个示例
那么，我们能不能创造出一种，利用有限的8位机器数，尽可能多的解决上述问题的方法呢？
假设，机器位为8，有如下的一段2进制编码：
符号位 ：0表示正值， 1表示负值；
指数位 ：就是我们理解的平方数，在这里由于是2进制，所以，指数位的010暂且表示为 2 010 = 2 2 ，且指数的表示范围为0 ~ 7之间。（一会说这样做的问题）
数值位 ：就是我们要表示的真实的值的部分，但是，这里的1010并不是我们通常理解的10进制 的10，因为我们要在这解决上述定点数的问题,
那么，我们怎么设计才能让一条整数，小数共存的数据表示在一个硬件中呢？且简单易懂？
但是，以（0.）作为约定的数值位默认头是有问题的，比如：
真值 +0.001010 以我们自定义规则转换成的二进制为,
0000 0010 ，因为机器位数为8，超过的8位要舍去，10就被丢掉了，损失了精度且保留了多余的，没有意义的0 。
这就引出了我们要解决的问题4
看来，我们现在需要对规则进行一些修改，我们尝试以（1.）作为约定的数值位默认头，还是以真值 +0.001010为例 ，那么这个真值可以改写为
1.010 x 2 -3 == 1.010 x 2 -011
这回可操蛋了，因为之前我们约定的指数部分的表示范围是0 ~ 7，这个-3可怎么办呢，聪明的你肯定想到了，何不把指数位置的第一位也规定为符号位呢？这不就可以表示正负数了吗，没错，是可以满足需求，但是，多一个符号位的判断会增加机器的运算复杂度负担，那么可以用补码啊？没错，但是，如果通过指数进行数值比较的时候（注意：在对两个值进行判断的时候，例如 3 >4，计算机浮点运算器会对 3 和 4 对应的64位浮点数指数位数值进行比较，如果不相等，直接返回true或false，如果想等，再进行数值位的比较），又要增加负担，有没有更好的办法呢？
可推理出
真值 +0.001010 == 1.010 x 2 -3 == 1.010 x 2 -011
得指数真实表示的值为 -011 + 偏移值 011 == 000
真值 +0.001010 的自定义2进制编码值为
0000 0100
经过以上的求证，得到新的8位机器数浮点数约定如下：
所以，图1-1使用我们新约定的浮点数规则解码，得到：
1.1010 x 2 010-011=-1 == 0.11010
+0.11010 == 0.9140625
先说间隙值
再说数值范围
我们再回过头来看看IEEE754,由于js使用的是IEEE754双精度浮点格式（64 位），所以我们就针对64位说明。其实，和我们上面自己胡编乱造的规则基本一样，
IEEE754双精度浮点格式
符号位1，指数位11，数值位52，偏移值 2 11-1 - 1 == 1023
现在，我们可以自己证明
因为数值位是52位，加上约定的隐藏头1. 那么就是 53位，超出的部分舍弃，所以就是精度损失
但严谨来说，应该是不包含小数
已经证明过
我们先把0.1 和 0.2 转化为2进制
很明显，0.1 和 0.2 都无法用2进制精准表示，呈现出的是无限循环。
我们看一个实例，来看看IEEE如何做舍入处理的
（例子是IEEE754单精度浮点格式（32 位），没找到64位的，自己懒得算了。。不过可以说明问题）
0.1被IEEE754双精度浮点数舍入处理后的值为
0.00011001100110011001100110011001100110011001100110011010
0.2被IEEE754双精度浮点数舍入处理后的值为
0.0011001100110011001100110011001100110011001100110011010
0.1 和 0.2 在转换后都被进位了，所以实际值，比真实值要大一点点，所以0.1+0.2比0.3略大，暂且这么来理解，因为浮点数的运算比定点数要麻烦，又由于10.1假期结束，至此一阶段笔记到此结束，之后的二阶段再补浮点数运算的笔记
参考资料
计算机组成原理
http://c.biancheng.net/view/314.html
https://www.zhihu.com/question/21711083
https://blog.csdn.net/weixin_40805079/article/details/85234878
