go 语言中，`context` 是处理请求生命周期、传递取消信号、超时控制和跨组件共享请求元数据的核心机制；它替代了其他语言中的“线程局部存储”，通过显式传递实现清晰、可控、可测试的请求边界管理。
在 Go 的 HTTP 服务开发中，context.Context 并非可选工具，而是构建健壮、可观测、可中断服务的基础设施。它的核心价值体现在两个维度：请求生命周期管理（如超时、取消）和请求上下文传播（如 trace ID、用户身份、原始请求头等元数据）。由于 Go 不提供类似 C# HttpRequest.Current 的隐式全局请求上下文，所有上下文信息必须在请求入口处显式创建，并逐层传递——这是 Go “显式优于隐式”哲学的典型实践。
✅ 正确初始化请求 Context（推荐方式）
应从 http.Request.Context() 获取基础 context（它已内置了请求取消信号），再按需派生子 context：
func handler(w http.ResponseWriter, r *http.Request) {
// ✅ 推荐：复用标准库已封装的 request context（含 CancelFunc）
ctx := r.Context()
// ? 添加超时：若整个处理不能超过 800ms
ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
defer cancel() // 防止 goroutine 泄漏！
// ?️ 注入业务相关值（如用户 ID、trace ID）——注意：仅限不可变、轻量、必要数据
ctx = context.WithValue(ctx, "userID", getUserIDFromToken(r))
ctx = context.WithValue(ctx, "traceID", getTraceID(r))
// ? 传递给下游服务（DB、RPC、缓存等）
result, err := userService.FetchProfile(ctx, "123")
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
http.Error(w, "Request timeout", http.StatusGatewayTimeout)
return
}
http.Error(w, "Internal error", http.StatusInternalServerError)
return
}
json.NewEncoder(w).Encode(result)
}⚠️ 注意事项：永远不要用 context.Background() 替代 r.Context()：前者无取消能力，会丢失 HTTP 连接关闭/客户端中断信号；context.WithValue 仅用于传递请求范围的元数据（metadata），而非业务参数：应定义强类型 key（如 type ctxKey string; const userIDKey ctxKey = "userID"），避免字符串 key 冲突与类型不安全；务必调用 cancel()（尤其在 WithTimeout/WithCancel 后）：否则可能引发 context 泄漏，导致 goroutine 持有已结束请求的资源。
? Context 如何驱动下游组件协作？
Context 的 Done() channel 是协作取消的关键。下游组件需主动监听并响应：
func (db *DB) Query(ctx context.Context, sql string, args ...any) (*Rows, error) {
// 启动查询前检查是否已被取消
select {
case <-ctx.Done():
return nil, ctx.Err() // 如 context.Canceled 或 context.DeadlineExceeded
default:
}
// 执行实际查询（例如：调用 database/sql 的 QueryContext）
rows, err := db.sqlDB.QueryContext(ctx, sql, args...)
if err != nil {
return nil, err
}
return &Rows{rows: rows}, nil
}标准库中多数 I/O 操作（http.Client.Do, database/sql.QueryContext, net.Conn.SetDeadline 等）均已支持 context.Context，无需手动轮询 Done() —— 直接传入即可获得自动超时与取消。
? 为什么 Context 被高频使用？三个关键收益
| 场景 | 传统做法痛点 | Context 解决方案 |
|---|---|---|
| 分布式追踪 | 每层硬编码提取 X-Request-ID 头 | ctx = context.WithValue(r.Context(), TraceKey, r.Header.Get("X-Request-ID"))，统一透传 |
| 级联超时 | 各服务独立设超时，总耗时不可控 | 入口统一 WithTimeout，所有下游自动继承并响应 |
| 优雅关机 | 正在处理的请求被粗暴中断 | server.Shutdown() 触发 r.Context().Done()，各组件可清理资源后退出 |
✅ 总结：Context 使用最佳实践
- ✅ 入口统一创建：HTTP handler 中优先使用 r.Context()，再派生；
- ✅ 超时由上层设定：业务逻辑不硬编码超时，由入口或中间件统一控制；
- ✅ 元数据有限注入：只存必要、不可变、低开销的请求标识类数据；
- ✅ 下游主动响应：所有阻塞操作必须接受 context.Context 并监听 Done()；
- ❌ 禁止滥用 WithValue：不传大对象、不传函数、不传可变状态；
- ❌ 禁止忽略 cancel()：WithCancel/WithTimeout 后必须 defer 调用。
Context 是 Go 构建云原生服务的“胶水”，它不解决具体业务问题，却为超时控制、可观测性、优雅终止提供了统一契约。理解它，就是理解 Go 在并发与可靠性之间的精妙平衡。
