和大家分享一個有趣的測試：

0.1+0.2 == 0.3 //false
頓時郁悶，好吧！原來0.1+0.2變成：0.30000000000000004
再來一個 2.4/0.8 =>2.9999999999999996 沒辦法換種方式，都轉(zhuǎn)換成整數(shù) (2.4 * 100)/(0.8 * 100)
10.22 現(xiàn)在要減去 0.11 結(jié)果值又出現(xiàn)了很多的小數(shù) 10.110000000000001，然后我就用了 toFixed 方法來過濾小數(shù)，但是不知道跟前面那種轉(zhuǎn)換成整數(shù)后再執(zhí)行哪種效率高，好！還是試下再說吧！

var date1 = new Date();
for(var i = 0; i < 10000; i++){
 var result1 = (10.22 - 0.11).toFixed(2);    
}
alert(new Date() - date1);//效率低
  
var date2 = new Date();
for(var j = 0; j < 10000; j++){
 var result2 = (10.22 * 1000 - 0.11 * 1000) / 1000;    
}
alert(new Date() - date2);//效率高
 
alert(0.1 + 0.2 == 0.3); //既然返回false
alert(0.1 + 0.2); //既然返回0.30000000000000004
alert(parseFloat(0.1) + parseFloat(0.2)); //還是返回0.30000000000000004

查了一些資料，一是 JavaScript 浮點數(shù)計算的 Bug，另一個是和計算機最終轉(zhuǎn)換成二進制計算有關(guān)系，但是為什么不是所有小數(shù)都會有這種現(xiàn)象，目前我也不清楚，有時間再去深入研究一下。

解決方法：
解決這種問題兩種方法，第一種就是利用JavaScript 的toFixed(n) 方法，直接獲取N 位小數(shù)，不過，個人覺得這種方法在數(shù)據(jù)精度上會有一些問題。如果數(shù)據(jù)精度要求不高的話可以使用。

alert((0.1 + 0.2).toFixed(1));

第二種方法就是自己編寫運算方法。以下是自定義加法函數(shù)，使用此方法進行相加會避免上面問題。

//自定義加法運算
function addNum (num1, num2) {
 var sq1,sq2,m;
 try {
  sq1 = num1.toString().split(".")[1].length;
 }
 catch (e) {
  sq1 = 0;
 }
 try {
  sq2 = num2.toString().split(".")[1].length;
 }
 catch (e) {
  sq2 = 0;
 }
 m = Math.pow(10,Math.max(sq1, sq2));
 return (num1 * m + num2 * m) / m;
}
alert(addNum(0.1, 0.2));

當然，簡單一點也可以寫成：alert((num * 3 + 10 * 3) /3); 這樣也不會出現(xiàn) N 多位小數(shù)。
alert((num * 3 + 10 * 3) /3); 與 alert(num + 10); 這兩種寫法計算機在底層轉(zhuǎn)換成二進制運算是有區(qū)別的，或許這就是出現(xiàn)上述問題的原因，還有待我們?nèi)ド钊胙芯?，大家可以多多討論?/p>