眾所周知，JavaScript 浮點數運算時經常遇到會0.000000001和0.999999999這樣奇怪的結果，如0.1+0.2=0.30000000000000004、1-0.9=0.09999999999999998，很多人知道這是浮點數誤差問題，但具體就說不清楚了。本文幫你理清這背後的原理以及解決方案，還會向你解釋JS中的大數危機和四則運算中會遇到的坑。

浮點數的儲存

首先要搞清楚 JavaScript 如何儲存小數。和其它語言如 Java 和 Python 不同，JavaScript 中所有數字包括整數和小數都只有一種型別 —Number。它的實現遵循IEEE 754標準，使用 64 位固定長度來表示，也就是標準的 double 雙精度浮點數（相關的還有float 32位單精度）。計算機組成原理中有過詳細介紹，如果你不記得也沒關係。

這樣的儲存結構優點是可以歸一化處理整數和小數，節省儲存空間。

64位位元又可分為三個部分：

• 符號位S：第 1 位是正負數符號位（sign），0代表正數，1代表負數
• 指數位E：中間的 11 位儲存指數（exponent），用來表示次方數
• 尾數位M：最後的 52 位是尾數（mantissa），超出的部分自動進一舍零

實際數字就可以用以下公式來計算：
$ V = (-1)^{S}\times M \times 2^{E} $

注意以上的公式遵循科學計數法的規範，在十進位制是為0<M<10，到二進行就是0<M<2。也就是說整數部分只能是1，所以可以被捨去，只保留後面的小數部分。如 4.5 轉換成二進位制就是 100.1，科學計數法表示是 1.001*2^2，捨去1後M = 001

最終的公式變成：

$ V = (-1)^{S}\times (M+1) \times 2^{E-1023} $

所以4.5最終表示為（M=001、E=1025）：

下面再以0.1例解釋浮點誤差的原因，0.1轉成二進位制表示為0.0001100110011001100(1100迴圈)，1.100110011001100x2^-4，所以E=-4+1023=1019；M 捨去首位的1，得到100110011...。最終就是：

轉化成十進位制後為0.100000000000000005551115123126

為什麼0.1+0.2=0.30000000000000004？

計算步驟為：

// 0.1 和 0.2 都轉化成二進位制後再進行運算
0.00011001100110011001100110011001100110011001100110011010 +
0.0011001100110011001100110011001100110011001100110011010 =
0.0100110011001100110011001100110011001100110011001100111

// 轉成十進位制正好是 0.30000000000000004

為什麼x=0.1能得到0.1？

恭喜你到了看山不是山的境界。因為 mantissa 固定長度是 52 位，再加上省略的一位，最多可以表示的數是2^53=9007199254740992，對應科學計數尾數是9.007199254740992，這也是 JS 最多能表示的精度。它的長度是 16，所以可以使用toPrecision(16)來做精度運算，超過的精度會自動做湊整處理。於是就有：

0.10000000000000000555.toPrecision(16)
// 返回 0.1000000000000000，去掉末尾的零後正好為 0.1

// 但你看到的 `0.1` 實際上並不是 `0.1`。不信你可用更高的精度試試：
0.1.toPrecision(21) = 0.100000000000000005551

大數危機

可能你已經隱約感覺到了，如果整數大於 9007199254740992 會出現什麼情況呢？
由於 E 最大值是 1023，所以最大可以表示的整數是2^1024 - 1，這就是能表示的最大整數。但你並不能這樣計算這個數字，因為從2^1024開始就變成了Infinity

> Math.pow(2, 1023)
8.98846567431158e+307

> Math.pow(2, 1024)
Infinity

那麼對於(2^53, 2^63)之間的數會出現什麼情況呢？

• (2^53, 2^54)之間的數會兩個選一個，只能精確表示偶數
• (2^54, 2^55)之間的數會四個選一個，只能精確表示4個倍數
• ... 依次跳過更多2的倍數

下面這張圖能很好的表示 JavaScript 中浮點數和實數（Real Number）之間的對應關係。我們常用的(-2^53, 2^53)只是最中間非常小的一部分，越往兩邊越稀疏越不精確。

在淘寶早期的訂單系統中把訂單號當作數字處理，後來隨意訂單號暴增，已經超過了
9007199254740992，最終的解法是把訂單號改成字串處理。

要想解決大數的問題你可以引用第三方庫bignumber.js，原理是把所有數字當作字串，重新實現了計算邏輯，缺點是效能比原生的差很多。所以原生支援大數就很有必要了，現在 TC39 已經有一個 Stage 3 的提案proposal bigint，大數問題有問徹底解決。

toPrecisionvstoFixed

資料處理時，這兩個函式很容易混淆。它們的共同點是把數字轉成字串供展示使用。注意在計算的中間過程不要使用，只用於最終結果。

不同點就需要注意一下：

• toPrecision是處理精度，精度是從左至右第一個不為0的數開始數起。
• toFixed是小數點後指定位數取整，從小數點開始數起。

兩者都能對多餘數字做湊整處理，也有些人用toFixed來做四捨五入，但一定要知道它是有 Bug 的。

如：1.005.toFixed(2)返回的是1.00而不是1.01。

原因：1.005實際對應的數字是1.00499999999999989，在四捨五入時全部被捨去！

解法：使用專業的四捨五入函式Math.round()來處理。但Math.round(1.005 * 100) / 100還是不行，因為1.005 * 100 = 100.49999999999999。還需要把乘法和除法精度誤差都解決後再使用Math.round。可以使用後面介紹的number-precision#round方法來解決。

解決方案

回到最關心的問題：如何解決浮點誤差。首先，理論上用有限的空間來儲存無限的小數是不可能保證精確的，但我們可以處理一下得到我們期望的結果。

資料展示類

當你拿到1.4000000000000001這樣的資料要展示時，建議使用toPrecision湊整並parseFloat轉成數字後再顯示，如下：

parseFloat(1.4000000000000001.toPrecision(12)) === 1.4  // True

封裝成方法就是：

function strip(num, precision = 12) {
  return +parseFloat(num.toPrecision(precision));
}

為什麼選擇12做為預設精度？這是一個經驗的選擇，一般選12就能解決掉大部分0001和0009問題，而且大部分情況下也夠用了，如果你需要更精確可以調高。

資料運算類

對於運算類操作，如+-*/，就不能使用toPrecision了。正確的做法是把小數轉成整數後再運算。以加法為例：

/**
 * 精確加法
 */
function add(num1, num2) {
  const num1Digits = (num1.toString().split('.')[1] || '').length;
  const num2Digits = (num2.toString().split('.')[1] || '').length;
  const baseNum = Math.pow(10, Math.max(num1Digits, num2Digits));
  return (num1 * baseNum + num2 * baseNum) / baseNum;
}

以上方法能適用於大部分場景。遇到科學計數法如2.3e+1（當數字精度大於21時，數字會強制轉為科學計數法形式顯示）時還需要特別處理一下。

能讀到這裡，說明你非常有耐心，那我就放個福利吧。遇到浮點數誤差問題時可以直接使用
github.com/dt-fe/numbe…

完美支援浮點數的加減乘除、四捨五入等運算。非常小隻有1K，遠小於絕大多數同類庫（如Math.js、BigDecimal.js），100%測試全覆蓋，程式碼可讀性強，不妨在你的應用裡用起來！

參考並轉載於：https://github.com/camsong/blog/issues/9