在 JavaScript 中 0.1 + 0.2 会是多少？为什么？如何避免相关问题？

JavaScript 与多数程式语言一样，当我们把 0.1 + 0.2 时，会出现一个怪异的数字，如果没有特别做处理的话，可能会产生错误；如果是做对数字精确度ㄧ要求高的产品(例如金融类的产品)，这是一定要避免的问题。也因此在 JavaScript 面试中这也是常考的基础题。

0.1 + 0.2 会是多少？

会是 0.30000000000000004

为什么会是 0.30000000000000004？

这不是 JavaScript 独有的现象，而是使用二进制浮点运算的程式语言都会遇到的问题。而 JavaScript 中用到小数点时，因为 JavaScript 是采用 IEEE 754 六十四位元双精度浮点数，所以会遇到这个问题。

在一般生活中，我们多数情况是使用十进位，而要能够精确表达十进位，而 10 的质因数是 5 与 2，所以只有 1/2、1/4、1/5、1/8、1 /10 这几个数能够被十进位的小数清楚表达；而像是 1/3、1/6、1/7、1/9 则不行。以 1/3 来说，我们知道会是 0.33333333 一路到无穷无尽。

而对于二进位制来说，只有 1/2、1/4、1/8 等可以被清楚表达，其他则会无穷无尽地延伸下去，然而因为电脑的记忆体有限，程式语言会分配给一个数字的记忆体也是有限，所以在精准度的表达下会有其限制，这也是导致 0.30000000000000004 这个怪异数字的原因。

该如何避免相关问题？

在 JavaScript 中有toFixed 以及toPrecision 等给数字操作的方法，让我们能够设定我们要的精确度，举例来说，可以设定精确到小数第一位。因此

console.log((0.1 + 0.2).toFixed(1)); // 0.3
console.log((0.1 + 0.2).toPrecision(1)); // 0.3

不过这些方法都有一些限制，例如假如某个数是动态算出来的，就没办法预先在 toFixed 当中去写要精确到第几位数。因此比较多人会选择用套件来处理。

社群中有一些热门的 JavaScript 套件，以下几个是 GitHub 上星星数多的

另外，近期有一个新的专案 nstr，该专案的解法专注在最终 UI 呈现上，如何避免这种怪异数字呈现的问题 (而不是专注在浮点数计算本身)，大概一百行左右的程式码，把各类的极端状况都处理掉，蛮推荐可以一读原始码。

不用浮点数，或者改良浮点数计算

事实上在一些追求高精度数字的产业，例如金融产业，很多甚至会直接选择不用浮点数，所有的计算都变成整数运算，完全避开浮点数的精度问题。例如 1 美元 5 分，比起用 1.05，会直接用 105。

由于浮点数的存在还是有其价值，假如直接用整数，也可能造成一些问题，所以业界也有做法是采用改良式的浮点数，例如 1.05 元变成 (1050000.0)。这样可以精确表示 0.000001 到 9999999999.999999 之间的数值。

这做法如果超出上述的范围，虽然还是能表示，但仍会有精度问题，所以范围要拉多广，端看系统需求而定。

有些程式语言 (例如 Java) 会有 BigDecimal 这种能解决精度问题的型别，但在空间和时间复杂度上可能会有额外的效能负担，因此除非是真的需要到某个精度，不然通常是不必要的，改良版的浮点数方案通常就很够用。

因此如何选择，最终仍是要回到系统需求，根据实际需求和效能考量来选择最适合的方案。