至于为什么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 中精度问题以及解决方案
0.1+0.2 != 0.3，怎么解决?(1) 在计算机中，数字无论是定点数还是浮点数都是以多位二进制的方式进行存储的。存储一个数值所使用的二进制位数比较多,这样得到的数会更加精确。
(2) 由于存储空间有限，无法整除的小数的时候就会取一个近似值，在js中如果这个近似值足够近似，那么js就会认为他就是那个值。
(3) 在0.1 + 0.2这个式子中，0.1和0.2都是近似表示的，在他们相加的时候，两个近似值进行了计算，导致最后得到的值是0.30000000000000004，此时对于JS来说，其不够近似于0.3，于是就出现了0.1 + 0.2 != 0.3 这个现象。
当然，有时两个近似值进行计算的时候，得到的值是在JS的近似范围内的，于是就可以得到正确答案。
(4) 解决办法:
就是我们想办法规避掉这类小数计算时的精度问题,那么最常用的方法就是将浮点数转化成整数计算。因为整数都是可以精确表示的。
对于0.1 + 0.02 我们需要转化成 ( 10 + 2 ) / 1e2
公共方法使用
