Go 程式碼審查
目標：變更應使程式碼庫變得更健康，不一定要完美。 請勿因個人偏好而阻擋變更。
步驟 1：取得變更
- 如果使用者提供了 diff、PR 或檔案，請直接使用。
- 在 git 儲存庫中：執行
git diff --stat main...HEAD，然後執行git diff main...HEAD（若main不存在，請嘗試master或origin/main）。 對於未提交的工作：執行git diff和git diff --staged。 - 如果變更的目的不明確，請用一行簡短提問。
步驟 2：閱讀上下文
- 開啟每個變更函式周圍的整個檔案，而不僅僅是 diff 行。
- 尋找變更的匯出函式的呼叫者：執行
grep -rn "FuncName(" --include=*.go - 檢查
go.mod中的 Go 版本。某些建議會依賴於此 （自 Go 1.22 起，迴圈變數為每次迭代獨立）。
步驟 3：執行工具（如果你可以執行命令）
go build ./...
go vet ./...
go test -race ./... # 如果儲存庫較慢，僅測試變更的套件
golangci-lint run ./... # 僅在已安裝或儲存庫有設定檔時執行
報告實際的失敗。關於格式化，只需說「執行 gofmt」一次；不要列出每一行。 如果你無法執行命令，請用一行說明。
步驟 4：依此順序審查
先處理大事項。如果設計有誤，先說出來，然後跳過小問題。
- 設計 – 此變更是否適合放在這裡（此套件、此服務）？是否符合系統的其他部分？現在做這個變更的時機是否恰當？
- 功能 – 它是否完成了作者想要的事情？這對使用它的人（最終使用者和未來的開發者）是否有利？請考慮邊界情況和並發。
- 複雜度 – 讀者能否快速理解？注意過度工程：為想像中的未來而不是當前的問題所設計的程式碼。
- 測試 – 同次變更中是否有測試？如果程式碼壞掉，測試是否會失敗？測試是否簡單？
- 命名 – 清晰、不過長、符合 Go 風格。
- 註解 – 解釋為什麼，而不是做什麼。移除過時的註解和已完成的 TODO。
- 風格 – gofmt、風格指南。個人偏好 = 僅為小問題。
- 一致性 – 風格指南優先於周圍程式碼。如果指南未說明，則遵循周圍程式碼。
- 文件 – 如果行為改變，請更新 README、godoc、設定/環境變數、遷移。
- 每一行 – 閱讀所有人工編寫的程式碼。生成的程式碼（
*.pb.go、mock、sqlc 輸出）可以略讀。 - 程式碼健康度 – 此變更讓整個系統變得更好還是更差？
- 優點 – 指出你看到的實際優點。
針對每個領域的 Go 特定檢查，請閱讀 references/go-checklist.md。
務必檢查其中的錯誤、並發和資源區段；大多數 Go 錯誤都在這裡。
嚴重程度標籤
- 封鎖 – 錯誤、資料競爭、goroutine 洩漏、安全性問題、損壞的測試、錯誤的設計。必須在合併前修復。
- 應修復 – 真實問題，但不緊急。作者可以辯論。
- 小問題 – 可選的小改進。註解開頭請一律加上「Nit:」。
- 疑問 – 你不理解的內容。如果你無法理解，其他人也可能無法理解；請要求更清晰的程式碼。
請勿憑空發明問題。良好的變更會得到簡短的審查。 如果你不確定某件事是否為錯誤，請使用疑問，而不是封鎖。 如果要求僅審查某些檔案或面向，請說明你審查了哪些部分。
輸出格式
## 摘要
1–2 句話：變更的內容。結論：核准 / 附帶意見核准 / 需要變更。
## 封鎖事項
- `path/file.go:42` – 問題是什麼以及為何重要。
```go
// 建議的修正
```
## 應修復事項
## 小問題
## 疑問
## 優點
## 我檢查了什麼
已執行的工具與結果、已審查的檔案、任何跳過的項目。
留空不輸出區段。每個意見：問題、原因、修正。保持簡短。