JavaScript 中精度問題及解決思路彙總

導讀	JavaScript 中的數字按照 IEEE 754 的標準，使用 64 位雙精度浮點型來表示。其中符號位 S，指數位 E，尾數位M分別佔了 1，11，52 位，並且在 ES5 規範 中指出了指數位E的取值範圍是 [-1074, 971]。

想用有限的位來表示無窮的數字，顯然是不可能的，因此會出現一些列精度問題：

1. 浮點數精度問題，比如 0.1 + 0.2 !== 0.3
2. 大數精度問題，比如 9999 9999 9999 9999 == 1000 0000 0000 0000 1
3. toFixed 四捨五入結果不準確，比如 1.335.toFixed(2) == 1.33

浮點數精度和 toFixed 其實屬於同一類問題，都是由於浮點數無法精確表示引起的，如下：

(1.335).toPrecision(20);    // "1.3349999999999999645"

而關於大數精度問題，我們可以先看下面這個程式碼片段：

// 能精確表示的整數範圍上限,S為1個0，E為11個0，S為53個1
Math.pow(2, 53) - 1 === Number.MAX_SAFE_INTEGER    // true
// 能精確表示的整數範圍下限,S為1個1，E為11個0，S為53個1
-(Math.pow(2, 53) - 1) === Number.MIN_SAFE_INTEGER    // true
// 能表示的最大數字，S為1個0，E為971，S為53個1
(Math.pow(2, 53) - 1) * Math.pow(2, 971) === Number.MAX_VALUE    // true
// 能表示的最接近於0的正數，S為1個0，E為-1074，S為0
Math.pow(2, -1074) === Number.MIN_VALUE // true

透過以上可以明白， [MIN_SAFE_INTEGER, MAX_SAFE_INTEGER] 的整數都可以精確表示，但是超出這個範圍的整數就不一定能精確表示。這樣就會產生所謂的大數精度丟失問題。

首先考慮的是如何解決浮點數運算的精度問題，有 3 種思路：

1. 考慮到每次浮點數運算的偏差非常小(其實不然)，可以對結果進行指定精度的四捨五入，比如可以parseFloat(result.toFixed(12));
2. 將浮點數轉為整數運算，再對結果做除法。比如0.1 + 0.2，可以轉化為(1*2)/3。
3. 把浮點數轉化為字串，模擬實際運算的過程。

先來看第一種方案，在大多數情況下，它可以得到正確結果，但是對一些極端情況，toFixed 到 12 是不夠的，比如：

210000 * 10000  * 1000 * 8.2    // 17219999999999.998
parseFloat(17219999999999.998.toFixed(12));    // 17219999999999.998，而正確結果為 17220000000000

上面的情況，如果想讓結果正確，需要 toFixed(2)，這顯然是不可接受的。

再看第二種方案，比如 number-precision 這個庫就是使用的這種方案，但是這也是有問題的，比如：

// 這兩個浮點數，轉化為整數之後，相乘的結果已經超過了 MAX_SAFE_INTEGER
123456.789 * 123456.789     // 轉化為 (123456789 * 123456789)/1000000，結果是 15241578750.19052

所以，最終考慮使用第三種方案，目前已經有了很多較為成熟的庫，比如 bignumber.js，decimal.js，以及big.js等。我們可以根據自己的需求來選擇對應的工具。並且，這些庫不僅解決了浮點數的運算精度問題，還支援了大數運算，並且修復了原生toFixed結果不準確的問題。

還有另外一個與 JavaScript 計算相關的問題，即 Math.round(x)，它雖然不會產生精度問題，但是它有一點小陷阱容易忽略。下面是它的舍入的策略：

1. 如果小數部分大於 0.5，則舍入到下一個絕對值更大的整數。
2. 如果小數部分小於 0.5，則舍入到下一個絕對值更小的整數。
3. 如果小數部分等於 0.5，則舍入到下一個正無窮方向上的整數。

所以，對 Math.round(-1.5)，其結果為 -1，這可能不是我們想要的結果。

當然，上面提到的 big.js 等庫，都提供了自己的 round 函式，並且可以指定舍入規則，以避免這個問題。

原文來自：