在 Go 語言中，context.Context 是一個核心概念，用于在 Goroutine 之間傳遞截止時間（deadline）、取消信號（cancellation signal）和請求范圍內的值。

然而，關于如何傳遞 Context，社區中存在一個長期的爭論：究竟是作為函數的第一個參數顯式傳遞，還是將其存儲在結構體中？

本文將詳細解析這兩種傳遞方式的優劣，并結合 Go 官方的建議和設計哲學，為你提供一個清晰的答案。

Go Context 的兩種傳遞方式

首先，我們通過一個簡單的示例來回顧 Context 的基本用法。

package main

import(
    "context"
    "fmt"
    "time"
)

// func1 模擬一個需要上下文控制的函數
func func1(ctx context.Context){
    select{
        case<-time.After(5* time.Second):
        fmt.Println("任務完成")
    case<-ctx.Done():
        fmt.Println("任務被取消:", ctx.Err())
    }
}

func main(){
    // 根 Context
    parentCtx := context.Background()
    // 創建一個帶 2 秒超時的子 Context
    ctx, cancel := context.WithTimeout(parentCtx,2*time.Second)
    defercancel()// 確保在函數退出時調用，釋放資源

    fmt.Println("開始執行任務...")
    func1(ctx)
    fmt.Println("主程序退出")
}

在上面的例子中，我們看到了 Context 作為函數參數傳遞的典型用法。現在，讓我們來探討兩種不同的傳遞方式：

1. 作為函數的第一個參數（官方推薦）

這種方式將 context.Context 作為函數的第一個參數顯式傳遞。

優點：

• 清晰、顯式： 函數簽名明確地表明它依賴于 Context。調用者一眼就能看出這個函數可以被取消、可以超時，或者需要一個特定的上下文。
• 避免隱式依賴： 防止 Context 被“隱藏”在結構體中，從而避免了意外的依賴。
• Go 官方慣例： 這是 Go 社區和標準庫的通用慣例，遵循這一模式可以使你的代碼更具可讀性和一致性。
• 無狀態：Context 是請求范圍的，將其作為參數傳遞，確保了每個請求都使用獨立的 Context，避免了狀態泄露。

缺點：

• “污染”函數簽名： 許多開發者抱怨每個函數簽名都必須加上 ctx context.Context，這使得函數簽名變得冗長，感覺像是“污染”了代碼。

2. 作為結構體的字段

這種方式將 context.Context 作為結構體的字段存儲，然后通過結構體的方法來使用它。

優點：

• 簡化函數簽名： 當一個結構體有很多方法時，將 Context 放在結構體中可以避免每個方法簽名都包含 ctx 參數，使得代碼看起來更簡潔。

缺點：

• 不安全：Context 是動態的、請求特定的。將它存儲在結構體中，意味著該結構體本身變成了有狀態的。你可能需要手動更新或重新創建結構體實例，否則就會導致同一個 Context 被多個請求共享，從而引發競態條件或邏輯錯誤。
• 反設計模式： 這種做法違背了 Context 作為臨時、請求范圍傳遞的設計初衷。一個長期存在的結構體不應該持有短暫的 Context 狀態。
• 易于混淆： 當你看到 T.Do() 方法時，你無法從簽名判斷它是否依賴于 Context，以及使用的是哪個 Context。這降低了代碼的可讀性。

官方的明確建議

Go 語言的 context 包文檔明確指出，使用 Context 的程序應遵循以下規則：

Do not store Contexts inside a struct type; instead, pass Contexts explicitly to functions.不要在結構體類型中存儲 Context；相反，將 Context 顯式地傳遞給函數。

官方的建議非常清晰，顯式傳遞是首選，并且應該作為函數的第一個參數，通常命名為 ctx。

這背后的設計理念是：Context 就像一個特殊的**“參數”**，它攜帶了關于請求的元信息，應該像其他參數一樣被傳遞。將它放入結構體，就像將 name 和 age 這樣的參數也放入結構體一樣，是不符合 Go 慣例的。

結論與實踐建議

盡管 Go 核心團隊成員 Brad Fitzpatrick 曾對此提出一些更靈活的看法，但在 Go 語言的實際開發和開源社區中，將 context.Context 作為函數第一個參數顯式傳遞，已經成為不可動搖的黃金準則。

• 對于Context的使用，請始終將其作為函數的第一個參數傳遞。
• 不要將Context存儲在結構體字段中。
• 如果函數不需要 Context，就不要傳遞它。
• 如果你有一個臨時的、特定于某個操作的結構體，并且該結構體的生命周期與 Context 嚴格綁定，那么可以考慮將 Context 嵌入其中。但這種場景非常罕見，通常可以通過其他方式重構。

通過遵循這些規則，你的 Go 代碼將更具可讀性、可維護性和健壯性，同時也能與 Go 生態系統保持高度的一致性。