谷歌工程師吐槽：0.1+0.2≠0.3，這bug藏了50年沒人管

「0.1加0.2等于0.30000000000000004。」這不是某個實習生寫的爛代碼，是IEEE 754浮點標準（二進制浮點數算術標準）在JavaScript、Python、Java里跑了半個世紀的"正確"結果。

一位谷歌工程師最近在技術博客復盤分數運算時，把這個問題重新拽回開發者視野。他說得很直接：浮點數的精度陷阱，本質上是我們用十進制的大腦去猜二進制的心思，猜錯了。

1960年代的遺產：為什么0.1在電腦里是無限循環小數

故事要從1960年代說起。當時計算機科學家面臨一個選擇：用二進制表示小數，還是用十進制？二進制贏了，因為硬件實現更快、更省硅片。

但代價是隱形的。十進制的0.1，換成二進制是0.0001100110011...無限循環。IEEE 754標準只能存64位，剩下的尾巴被砍掉。單次誤差小到10^-16級別，但疊加幾千次，財務系統里的 penny 就開始莫名其妙消失。

2008年，歐洲航天局阿麗亞娜5號火箭發射37秒后自毀，2億美元炸成煙花。事后調查發現，一個64位浮點數被塞進16位整數，溢出報錯。導航系統判定"出錯了"，觸發自毀程序。這不是分數運算的鍋，但屬于同一類問題：人類以為"差不多就行"，機器較真起來要命。

分數運算的古老規則，恰恰能避開這個坑。1/3加1/3加1/3，浮點數給你0.999999...，分數直接等于1。沒有近似，沒有累積誤差。

分數運算的三條鐵律：為什么通分比乘法更燒腦

加減法最折騰。3/7加5/11，你不能直接分子加分子、分母加分母。必須先找公分母，把兩塊不同大小的"披薩切片"切成同樣大小。

最笨的辦法：7乘11得77，分子變成33加35，結果68/77。但4/6加1/4，分母直接相乘得24，其實最小公倍數（LCD）是12。用LCD計算，中間數字更小，溢出風險更低。

乘法反而最簡單。分子乘分子，分母乘分母，3/7乘5/11直接得15/77。除法就是乘以倒數，把第二個分數上下翻轉。

每次運算完必須約分。24/36的最大公約數（GCD）是12，約成2/3。谷歌工程師在博客里貼了一段歐幾里得算法的JavaScript實現，十行代碼，跑了兩千年。

帶分數是人類的妥協，假分數是機器的母語。2又3/4寫成11/4，運算時少一層轉換。輸出時再換回帶分數，用戶看著舒服。

現代編程語言的分裂：誰還在用分數算錢

Python有fractions模塊，Java有BigDecimal，C#用decimal類型。這些都不是默認選項，得開發者主動想起來用。

金融領域早就學乖了。彭博終端、交易所核心系統，要么用定點數（fixed-point），要么直接用整數存"分"而不是"元"。1.23美元存成123，徹底避開浮點。

但科學計算和圖形渲染不一樣。物理模擬要速度，GPU用FP16、FP32滿天飛。誤差？每幀重新算，上一幀的偏差不累積。游戲畫面抖動一幀，玩家看不出來；銀行賬戶少一分錢，客服電話被打爆。

谷歌工程師的觀察是：分數運算在"需要精確"和"需要速度"的夾縫里存活。有理數庫（rational number library）存在，但調用成本比原生浮點高一個數量級。大多數開發者選擇"先跑起來，精度問題以后再說"——然后永遠沒以后。

一個木工師傅的啟示：為什么手工測量比CAD更準

文章結尾，作者講了一個場景。木工做柜子，CAD圖紙標了0.3333英尺，師傅直接拿尺子找1/3標記。十進制是給人看的，分數是給活干的。

編程同理。0.1+0.2的笑話流傳二十年，不是沒人想修，是修的成本比忍的成本更高。IEEE 754已成硬件標準，全世界CPU都認。要改？等于讓所有人換一把尺子。

但分數運算的知識沒有過時。2023年Stack Overflow調研顯示，"浮點數精度問題"仍是開發者搜索的前50話題之一，年搜索量超47萬次。每個搜這個問題的人，都在重新發現1960年代那個被砍掉的無限循環尾巴。