在Golang的Web服务里，一个HTTP请求从进入路由器到最终返回响应，通常会经过日志、认证、限流等若干中间件。请求级别的数据，比如用户ID、追踪ID、权限信息，需要在整条链路上共享；取消信号和超时控制则需要能跨层传递，及时中断不再需要的数据库查询或下游调用。标准库的context包就是为解决这类请求作用域问题诞生的。

严格来说，context并不是用来做依赖注入的容器，更不能替代结构化的参数传递。它的定位是携带请求生命周期内有效的信息，以及跟取消、超时相关的控制信号。理解好这一点，后面的实现方案才不会跑偏。

理解context包的核心API与传递模型

context.Context是一个接口，定义了四个方法：Deadline、Done、Err和Value。其中Done返回一个只读通道，当上下文被取消或超时时，通道会关闭；Err用来解释具体原因；Value则负责按照键查找请求范围内的数据。根上下文通常来自context.Background()，它没有超时和取消能力，一般作为整个请求链的起点。

上下文是不可变的，每次调用context.WithValue、context.WithTimeout或context.WithCancel都会返回一个新的上下文实例，而不是修改原来的对象。这个设计让并发请求之间不会互相污染。对于Web请求来说，最常见的做法是在请求进入时创建一个具备超时能力的根上下文，然后根据业务需要不断挂载新的键值对。

package main
import (
    "context"
    "fmt"
    "time"
)
func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
    select {
    case <-time.After(1 * time.Second):
        fmt.Println("任务完成")
    case <-ctx.Done():
        fmt.Println("任务被取消:", ctx.Err())
    }
}

在net/http中，每个*http.Request内部已经持有一个上下文，可以通过r.Context()获取。如果要向请求注入上下文，不能直接修改请求字段，而是使用r.WithContext(ctx)创建一个浅拷贝，这样不会影响原始请求对象。这个机制是中间件实现请求上下文管理的基础。

在中间件链中实现请求上下文的注入与读取

中间件是Web框架中天然的扩展点。以请求ID为例，入口中间件可以从请求头中读取X-Request-ID，如果不存在就生成一个，然后把这个ID写入上下文，再交给后续处理器。这样日志、监控、错误追踪等模块都能从同一个上下文里拿到同一个请求ID，定位问题时非常方便。

不过直接用字符串作为键存在安全隐患。不同包可能使用相同的字符串键，导致后写入的值覆盖先前的值。正确做法是定义私有类型作为键，例如type contextKey string，然后为每个业务键创建唯一的常量。这样即使两个包定义了同样内容的字符串，因为类型不同，也不会发生冲突。

type contextKey string
const (
    requestIDKey contextKey = "requestID"
    userIDKey    contextKey = "userID"
)
func WithRequestID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, requestIDKey, id)
}
func RequestIDFromContext(ctx context.Context) (string, bool) {
    id, ok := ctx.Value(requestIDKey).(string)
    return id, ok
}

在具体的中间件中可以这样使用上面的辅助函数：

func RequestIDMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := r.Header.Get("X-Request-ID")
        if id == "" {
            id = uuid.NewString()
        }
        ctx := context.WithValue(r.Context(), requestIDKey, id)
        r = r.WithContext(ctx)
        w.Header().Set("X-Request-ID", id)
        next.ServeHTTP(w, r)
    })
}

读取时则调用RequestIDFromContext(r.Context())拿到请求ID。采用返回布尔值的模式可以避免空接口类型断言失败时的panic，调用方可以自行决定默认值。对于需要跨多个中间件共享的用户身份、权限域等信息，也推荐使用同样方式封装成安全的读写函数。

上下文管理的常见陷阱与最佳实践

第一个常见误区是把所有东西都塞进上下文。数据库连接、日志器、配置对象这些全局或长生命周期的依赖，不应该放在context里。context的值只适合请求级别的信息，比如用户ID、请求ID、认证令牌解析结果、截止时间等。把全局依赖放进context会让函数签名看起来简洁，实际上隐藏了显式依赖，测试和审查代码时很难追踪。

第二个误区是使用context传递可选参数。例如根据请求参数决定是否跳过缓存，如果把布尔值放进上下文，业务函数内部再从上下文取，那么函数的行为就会变得不可预测。这类参数应该作为显式参数传递。上下文的值应该保持稳定，一旦放入，后续通常不再修改。

第三个容易忽略的问题是取消信号没有向下传递。如果在中间件中创建了带超时的上下文，却在调用下游服务时没有使用这个上下文，超时就不会生效。正确的做法是让所有接受上下文的函数都使用请求的context，比如数据库查询、HTTP客户端调用、gRPC调用等。这样当客户端断开连接或超时触发时，整条调用链能及时退出，避免资源浪费。

func HandleSlowTask(ctx context.Context, input string) error {
    select {
    case <-time.After(3 * time.Second):
        return doWork(input)
    case <-ctx.Done():
        return ctx.Err()
    }
}

另外，context的值在并发读取时是安全的，但不要尝试修改存入的值。如果存入的是一个可变的map或指针，使用方需要自己保证并发安全。键的设计要遵循不可导出原则，即键类型和常量不对外暴露，只通过函数读写。Go官方文档也建议不要在结构体中保存context，而是把context作为函数的第一个参数进行传递。

最后，合理设置超时可以显著提升服务稳定性。一个没有超时的请求可能一直占用连接和goroutine，而一个过短的超时又会误杀正常请求。可以根据接口的P99延迟设定一个稍宽松的请求级超时，再让各个下游调用使用更细粒度的超时。通过组合context.WithTimeout和context.WithValue，能够构建出一套清晰、可维护的请求上下文管理方案。