題干與適用場景
批次處理器需要並行處理一組物件，主 goroutine 等待全部任務結束，並在任一任務失敗或取消時停止繼續派發。請使用 Go 1.25 的 sync.WaitGroup.Go 設計生命週期，說明它與 Add、Done、Wait 的關係、panic 約束、錯誤傳播與取消邊界。題目適合後端、基礎設施與並行函式庫職位，核心考察並行任務生命週期，因此歸為 coding。
面試官考察點
第一，能否把「啟動任務」與「計數」綁定，避免 Add 放在錯誤位置造成 Wait 競態。
第二，能否理解 WaitGroup.Go 契約：傳入函式不得 panic，任務返回後計數自動遞減；它不提供錯誤值或取消傳播。
第三，能否設計有界並行、停止派發與結果收集，避免 goroutine 洩漏、資料競態與無限排隊。
第四，能否判斷何時改用 errgroup.WithContext，而不是把 WaitGroup 當作完整任務編排器。
第五，能否用測試覆蓋成功、取消、panic 防護與 Wait 競態，並說明 Go 版本與 CI 約束。
回答前需要澄清的問題
- 目標編譯器是否固定為 Go 1.25 或更高版本？
- 並行上限是多少，輸入是否可能無限流入？
- 首個錯誤是否應取消其餘任務，還是收集全部錯誤？
- 任務函式是否允許 panic，若不允許由哪一層恢復並轉為錯誤？
- 結果是否需要保持輸入順序，錯誤是否需要帶物件識別？
- 下游呼叫是否支援 context 取消與冪等重試？
30 秒回答框架
「我用 WaitGroup.Go 把每次啟動與計數綁定，用 semaphore 限制並行；任務入口檢查 context，把結果與錯誤寫入受保護的收集器。WaitGroup.Go 只負責等待，不負責錯誤或取消，所以首個錯誤需要明確取消衍生 context；若需要標準化的首錯傳播，我會使用 errgroup.WithContext。任務入口必須捕獲並轉換允許的 panic，測試覆蓋取消、並行上限、等待收斂與錯誤競態。」
分步驟深入解答
第一步：鎖定 API 契約
Go 1.25 在 sync.WaitGroup 增加 Go(f func())。它啟動 f 並在函式返回時執行等價的 Done；官方契約要求 f 不應 panic。專案應在 go.mod、CI 映像與本地工具鏈固定版本，避免舊編譯器無法識別方法。
第二步：把並行上限放在任務入口
使用有容量的 semaphore 在呼叫 Go 前或任務入口取得許可。若在派發迴圈中阻塞，應同時監聽 context，避免取消後仍繼續等待許可。
var wg sync.WaitGroup
sem := make(chan struct{}, 8)
for _, item := range items {
if err := ctx.Err(); err != nil { break }
sem <- struct{}{}
item := item
wg.Go(func() {
defer func() { <-sem }()
if ctx.Err() != nil { return }
process(item)
})
}
wg.Wait()第三步：設計錯誤與取消通道
WaitGroup 不儲存錯誤，也不會取消兄弟任務。衍生 context.WithCancel，任務首次寫入錯誤時呼叫取消；錯誤收集器使用 channel 或 mutex，讀取必須在 Wait 返回後完成，避免並行讀寫。
第四步：處理 panic 邊界
若業務允許把 panic 視為失敗，任務入口可用 defer + recover 將其轉換成帶堆疊的錯誤，再觸發取消。若 panic 表示程式不變量損壞，就不應靜默恢復；要在設計中明確記錄、監控與程序退出策略。
第五步：避免派發與等待競態
不要讓一個 goroutine 在另一個 goroutine 仍可能呼叫 Go 時直接 Wait，除非建立明確生命週期協定。批次處理器應由單一派發者決定何時停止新增任務，再呼叫 Wait；動態遞迴任務必須說明何時允許巢狀 Go。
第六步：比較 errgroup
errgroup.WithContext 提供首個非 nil 錯誤、衍生取消與可選並行上限，更適合「一個失敗就停止」的請求聚合。WaitGroup.Go 更適合只需等待、錯誤策略自訂或任務生命週期由其他元件管理的場景。
第七步：驗證關鍵不變量
測試應檢查每個啟動任務最終都會完成計數遞減；取消後不再派發新任務；錯誤只觸發一次取消；並行峰值不超過上限；Wait 返回後結果集合不再變化。使用 go test -race 捕獲結果收集器的資料競態。
高品質示範回答
「我先固定 Go 1.25。派發者在 context 未取消時取得 semaphore，然後呼叫 wg.Go；任務入口負責釋放 semaphore、檢查取消與執行處理。WaitGroup 只提供生命週期等待，不會傳播錯誤，因此我用衍生 context、帶物件識別的錯誤 channel 和一次性取消來實作首錯策略。允許恢復 panic 時把它轉換成錯誤並保留堆疊；不允許恢復時讓程序級策略接管。所有新任務停止派發後再 Wait，等待結束再彙總結果，並配合 go test -race 驗證。若需求是首錯取消和並行限制，我會優先 errgroup.WithContext。」
常見錯誤
- 把
WaitGroup.Go當錯誤組 → 錯誤不會自動傳播 → 明確收集錯誤或使用 errgroup。 - 取消後仍阻塞在 semaphore → 派發器無法退出 → 用
select同時監聽 context。 - 任務函式直接 panic → 違反 API 契約並可能中止程序 → 明確恢復轉換或讓程序策略接管。
- 多個 goroutine 同時修改 slice → 產生資料競態 → 用 channel、mutex 或任務結束後串行彙總。
- 派發者尚未結束就 Wait → 動態新增任務與等待交錯 → 建立停止派發協定。
- 只測最終數量 → 取消與並行峰值錯誤被掩蓋 → 逐項斷言不變量並執行 race detector。
- 忽略 Go 版本 → 本地可編譯、CI 失敗 → 鎖定 go.mod、映像與工具鏈。
- 用 WaitGroup 取代所有編排 → 重試、超時與首錯策略分散且難稽核 → 按需求選擇 errgroup 或專用調度器。
追問及應對
追問一：Go 能否傳入會 panic 的函式？
官方文件要求函式不得 panic。若系統把 panic 視為可恢復業務失敗，應在入口統一 recover 並轉換錯誤；否則保留 panic 語義並交由程序級恢復與告警策略。
追問二：如何保證取消後不再啟動任務？
派發前檢查 ctx.Err()，取得 semaphore 時使用可取消的 select，任務入口再次檢查 context。已啟動任務仍需依賴下游 API 回應取消。
追問三：何時 errgroup 更合適？
需要首錯、兄弟取消與統一等待時優先 errgroup.WithContext；只想等待獨立任務或需要自訂錯誤聚合時可用 WaitGroup.Go。
追問四：可以在等待期間繼續呼叫 Go 嗎？
只有在明確生命週期協定且計數不會從零重新變為正數的情況下才安全。常規批次應先停止派發，再呼叫 Wait，避免零計數與新增任務交錯。
追問五：如何實作結果有序？
為每個輸入分配索引，任務只寫入對應槽位或傳送帶索引的結果；等待結束後按索引彙總。不要讓多個任務透過 append 共用 slice。
追問六：如何測試 panic 恢復？
注入一個會 panic 的任務，斷言恢復層產生帶物件識別的錯誤、觸發取消且其他任務最終收斂；另測不恢復路徑，確認監控與程序策略符合約定。