JavaScript浮點數陷阱及解法
眾所周知，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} $
注意以上的公式遵循科學計數法的規范，在十進制是為0M = 001。E是一個無符號整數，因為長度是11位，取值范圍是 0~2047。但是科學計數法中的指數是可以為負數的，所以再減去一個中間數 1023，[0,1022]表示為負，[1024,2047] 表示為正。如4.5 的指數E = 1025，尾數M為 001。
最終的公式變成：
$ V = (-1)^{S}\times (M+1) \times 2^{E-1023} $
所以 4.5 最終表示為(M=001、E=1025)：
(圖片由此生成 http://www.binaryconvert.com/convert_double.html)
下面再以 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 會出現什么情況呢?
由于 M ***值是 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，大數問題有問徹底解決。
toPrecision vs toFixed
數據處理時，這兩個函數很容易混淆。它們的共同點是把數字轉成字符串供展示使用。注意在計算的中間過程不要使用，只用于最終結果。
不同點就需要注意一下：
- 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時，數字會強制轉為科學計數法形式顯示)時還需要特別處理一下。
能讀到這里，說明你非常有耐心，那我就放個福利吧。遇到浮點數誤差問題時可以直接使用
https://github.com/dt-fe/number-precision
***支持浮點數的加減乘除、四舍五入等運算。非常小只有1K，遠小于絕大多數同類庫(如Math.js、BigDecimal.js)，100%測試全覆蓋，代碼可讀性強，不妨在你的應用里用起來!
參考
- What Every Programmer Should Know About Floating-Point Arithmetic
- Why Computers are Bad at Algebra | Infinite Series
- Is Your Model Susceptible to Floating-Point Errors?
- IEEE 754
