如何用 Go 1.26 診斷 goroutine 洩漏並安全升級執行時？

1. 場景與成功標準

服務為每個批次啟動多個 worker，透過 channel 彙總結果；一旦某個 worker 回傳錯誤，呼叫方會提早返回。尖峰期間記憶體和 goroutine 數量逐漸上升，重啟執行個體後暫時恢復。升級目標包括：找到無法解除阻塞的 goroutine、保持取消語意、比較 Go 1.26 GC 變化，並給出可回滾發布計畫。

先定義基線：請求延遲分位數、吞吐量、堆積大小、GC CPU、活躍 goroutine、洩漏增長斜率和錯誤率。只看 runtime.NumGoroutine 無法判斷哪些 goroutine 真正洩漏。

2. Go 1.26 的相關變化

Go 1.26 引入實驗性的 goroutineleak pprof profile，用於報告因永久阻塞而無法喚醒的一類 goroutine；可透過 GOEXPERIMENT=goroutineleakprofile 啟用，並透過 net/http/pprof 暴露。它依賴垃圾回收器的可達性分析，無法識別所有洩漏，因此應視為診斷訊號，不是完整證明。

同一版本還提供 go fix modernizers、允許 new 接收運算式，以及預設啟用 Green Tea GC。升級應把語言便利、診斷實驗和執行時變化分開評估，避免把多個變數的效果混在一個基準裡。

3. 先建立最小洩漏重現

以下模式在遇到第一個錯誤時提早返回，但其他 worker 仍向無緩衝 channel 傳送，最後永久阻塞：

func processWorkItems(ctx context.Context, ws []WorkItem) ([]Result, error) {
    ch := make(chan result)
    for _, w := range ws {
        go func() {
            value, err := process(ctx, w)
            ch <- result{value: value, err: err}
        }()
    }

    results := make([]Result, 0, len(ws))
    for range ws {
        r := <-ch
        if r.err != nil {
            return nil, r.err
        }
        results = append(results, r.value)
    }
    return results, nil
}

用固定錯誤注入、重複執行和逐步增加批量大小觀察 goroutine 數量。重現必須包含呼叫方取消、逾時和正常完成路徑，避免只修復理想路徑。

4. 修復取消、關閉與背壓

讓傳送方尊重 ctx.Done()，並確保接收方取消後不會留下傳送者。可以使用帶緩衝 channel 配合明確容量，也可以讓一個協調 goroutine 負責關閉和彙總；不要讓多個 worker 競爭關閉同一個 channel。

select {
case ch <- result{value: value, err: err}:
case <-ctx.Done():
}

更完整的修復會在第一個錯誤時取消衍生 context，等待所有 worker 退出，再返回錯誤。errgroup.WithContext 可以統一這條生命週期，但仍需確認每個 worker 都傳播 context，並對外部 I/O 設定逾時。

5. 啟用 goroutineleak profile 與其他證據

在隔離環境使用 GOEXPERIMENT=goroutineleakprofile 建置，並透過受保護的 pprof endpoint 取樣。比較洩漏 profile、goroutine 堆疊、heap profile、trace 和業務指標的時間窗口；若 profile 沒有結果，不能推斷「沒有洩漏」，因為全域可達的阻塞原語可能無法被該機制判定。

把取樣放在壓測和故障注入期間，記錄 Go 版本、實驗開關、請求負載和取樣間隔。生產啟用前要限制 endpoint 存取、取樣頻率和資料留存，避免診斷介面成為資訊洩漏面。

6. 評估 Green Tea GC 與升級相容性

Go 1.26 預設啟用 Green Tea GC，官方說明其目標是改善小物件標記掃描的區域性和 CPU 可擴充性，但收益取決於工作負載。升級基準應分離 GC CPU、暫停時間、堆積峰值和請求延遲，並與舊版本在相同硬體、編譯選項和流量下比較。

如果觀測到回歸，短期可用 GOEXPERIMENT=nogreenteagc 做診斷對照，再決定是否回報問題；不要把實驗性回退當作永久架構方案。先在 canary 驗證資料競爭、cgo、外掛和依賴的相容性，再擴大流量。

7. 用 go fix 做可審計的現代化

go fix 基於與 go vet 相同的分析框架，可套用一組行為保持不變的 modernizers；Go 1.26 的新 new(expr) 語法就是典型目標。先在分支執行並審查每個 diff，再用編譯、單元測試、競態檢測和基準確認沒有改變語意。

不要為了「跟上版本」批量重寫所有程式。把自動修復與洩漏修復、GC 升級分開提交，確保回滾一個風險點不會帶走另一個修復；對生成程式碼和跨版本模組使用明確的 go 指令和建置約束。

8. 評分要點與追問

必須說清

• 能解釋 goroutine 洩漏的阻塞原因，並用取消、關閉和背壓修復生命週期。
• 知道 goroutineleak 是實驗 profile、基於可達性且不能覆蓋所有洩漏。
• 能把 Green Tea GC、go fix 和版本升級拆成獨立基準、canary 與回滾步驟。

常見追問

• 如果洩漏的 channel 被全域註冊表持有，profile 為何可能看不到？你會補什麼證據？
• 第一個錯誤發生後，如何確保正在阻塞的網路呼叫也能退出？
• 何時會選擇 GOEXPERIMENT=nogreenteagc，如何避免它掩蓋真正問題？

評分參考

優秀答案會把重現、生命週期修復、診斷證據和升級治理連成閉環：先讓每個 worker 可取消，再用 profile 與堆疊確認，最後用隔離基準和 canary 證明執行時升級安全。