工具-追根溯源

🎯 什麼情境該想到我

當你「只會照著公式/流程操作，卻不懂為什麼這樣做」，或想真正學到一個領域高手的思路、而不只是結論的時候。

對每個巧妙的方法問三個問題：提出它的人是誰？為什麼是「他/她」想到的？其思維方法有什麼特點？成為大師有偶然性，但更有必然性——必然性就是他們的思維方法。
追到最根本的源頭：不停在「怎麼做」，往回追到「這個想法從哪來、要解決什麼原始問題」。理解本質後，看似不同的問題常能用同一個模型解決（人類語言上千種，處理它們的數學模型卻相同或相似）。
學思維方法，而非背結論：作者刻意花大量篇幅寫科學家的日常與成功原因——因為可遷移的是他們「化繁為簡、追根究柢」的方法，不是某條具體公式。
反向自檢：你能不能講出這個方法「為什麼對、為什麼是這個而不是別的」？講不出，代表還停在表層，值得再往下挖。

註：站內沒有《數學之美》的原書檔。以下補充的公式與數字都可以自己推導或重算（計算以 Python 驗證，2026-09-25），不引用原書頁碼。

很多技術的價值在於它當初要解決的問題。只學用法，換一個情境就不會用；追到根，就能判斷什麼時候該用、什麼時候不該用。

技術	只學「怎麼做」	追到根
資料庫索引	查詢慢就加索引	磁碟隨機讀取很慢 → 用樹狀結構把 O(n) 掃描變成 O(log n) 次讀取 → 所以寫入要付出維護索引的代價，寫多讀少的表加索引可能反而變慢
Go 的 `context`	函式第一個參數放 `ctx`	要在一個請求的所有 goroutine 之間傳遞取消訊號與截止時間 → 所以不該把 `ctx` 存在 struct 裡、不該拿它傳業務參數
微服務	大系統就拆服務	要讓不同團隊能獨立部署 → 所以一個團隊的小系統拆成微服務，只有成本沒有收益

方法：讀一項技術時，找它的原始論文、設計文件、提案（proposal）。Go 的每個重要語言特性都有公開的設計提案，記錄了當時考慮過、但被否決的其他方案——那是「為什麼是這個而不是別的」的最佳答案。

能回答以下三個問題，才算追到根：

第 3 題最常被跳過——但正是它決定了你什麼時候不該用這個方法。