Go

主題索引（MOC）：寫 Go 時的慣用法、取捨與陷阱。先看下面的「三份來源怎麼分工」再往下挑工具——Go 的資料很容易讀到過期的版本。

📐 三份來源怎麼分工（重要，別讀錯輩分）

來源	回答什麼	變動速度	現況
Effective Go	Go 為什麼長成這樣（心智模型）	很慢	⚠️ 寫於 2009、官方明說不再更新。觀念成立，Errors 章與並行寫法已過時
Modern Go Guidelines	現在該用哪個 API	很快	對照表，涵蓋 Go 1.0 → 1.27
Google Go 風格指南	兩種寫法都合法時選哪個	中	Google 內部 readability 審查的依據；部分 API 為內部專屬

還有一份查證紀錄：Go Blog 經典六篇 —— 六篇官方經典逐篇對照現行文件的結果（哪篇能信、哪一句不能）。

建議順序：Effective Go 建立直覺 → Modern Go Guidelines 更新語法 → Google 風格指南學取捨。

✍️ 命名與可讀性

• 命名跟其他語言哪裡不一樣、縮寫大小寫、getter 要不要加 Get → 工具-Go命名慣例
• 兩種寫法都合法、review 吵不出結論、該不該引入新函式庫 → 工具-Go可讀性五原則

🧩 型別與介面設計

• 介面該多小、定義在哪一邊、該用介面還是泛型 → 工具-Go介面小而隱式
• 想省掉一堆轉發方法、嵌入到底是不是繼承 → 工具-Go嵌入機制
• 函式參數越加越多、要不要上 functional options → 工具-Go函式參數太多怎麼辦
• 想加 package 層級變數、註冊表或全域 client → 工具-Go全域狀態的判準

❌ 錯誤處理

• 哨兵／型別／不透明怎麼選、errors.Is／AsType／Join 怎麼用 → 工具-Go現代錯誤處理
• %v 還是 %w、%w 放哪、誰負責記 log、對外要不要暴露內部錯誤 → 工具-Go錯誤該包還是該轉

⚠️ 這兩張卡目前內容與 triggers 有重疊（包裝時機、重複 log），分工待重劃。暫時的區分：前者偏「錯誤值本身怎麼設計與判斷」，後者偏「往上傳時的包裝決策與邊界」。

🔀 並行

• 該用 channel 還是 mutex、goroutine 回不來、要做 worker pool → 工具-靠通訊共享記憶體
• 加逾時、取最快回應、time.After 會不會漏記憶體 → 工具-select超時與競速
• 懷疑有資料競爭但重現不了 → 工具-用race偵測器抓資料競爭

🧪 測試

• 測試紅了卻看不出哪裡錯、該不該用 assert 套件 → 工具-讓測試失敗訊息有用
• 一堆很像的案例重複貼、子測試名字怎麼取 → 工具-Go表格測試與子測試

🪤 語言陷阱

• defer 的執行順序與求值時機、recover 沒攔到 panic → 工具-defer-panic-recover
• 切片傳進函式被改到、append 之後資料變了、一小段切片釘住整個檔案 → 工具-Go切片的共享與陷阱
• reflect 改不動值、該用反射還是泛型還是程式碼產生 → 工具-Go反射三法則

🔗 跨領域（語言無關但寫 Go 一樣受用）

• 工具-有意義的命名、工具-函式短小且單一職責、工具-簡單清楚至上
• 工具-打破依賴以便測試、工具-測試先行的設計
• 工具-可靠可擴展可維護、工具-服務容錯設計
• 完整的工程主題總覽 → 軟體工程

📚 來源

• Effective Go、Modern Go Guidelines、Google Go 風格指南、Go Blog 經典六篇