应使用 context.WithValue 创建新 context 并通过 req.WithContext() 更新请求对象，再传给下一个 handler；key 需为自定义类型以避免冲突，取值须用对应 key 类型并判断 ok。
中间件里怎么把值塞进 context.Context 并传给下一个 handler
Go 的 HTTP 中间件本身不自动透传数据，必须显式用 context.WithValue 包装并重新赋值到 *http.Request 上。直接修改原始 req.Context() 不会生效，因为 req 是只读副本。
正确做法是：从 req.Context() 派生新 context，再用 req.WithContext() 生成新请求对象，最后调用 next.ServeHTTP(w, req)：
func AuthMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
userID := extractUserID(r.Header.Get("X-User-ID"))
ctx := context.WithValue(r.Context(), "user_id", userID)
r = r.WithContext(ctx) // 必须这一步！
next.ServeHTTP(w, r)
})
}
-
context.WithValue的 key 建议用自定义类型（如type ctxKey string），避免字符串冲突 - 不要用
map[string]interface{}或全局变量替代 context —— 会破坏请求隔离性 - 中间件链越长，嵌套 context 越深，但 Go runtime 对此无性能惩罚，无需担心
Handler 里怎么安全取 context.Context 里的值
取值必须用和写入时完全相同的 key 类型和值，否则返回 nil。常见错误是用字符串 key 写入，却用自定义类型 key 读取，或反过来。
推荐定义统一的 key 类型，并导出读写函数：
立即学习“go语言免费学习笔记（深入）”；
type ctxKey string
const UserIDKey ctxKey = "user_id"
func SetUserID(ctx context.Context, id int64) context.Context {
return context.WithValue(ctx, UserIDKey, id)
}
func GetUserID(ctx context.Context) (int64, bool) {
v := ctx.Value(UserIDKey)
id, ok := v.(int64)
return id, ok
}
- 永远用
ok判断是否取到值，不直接断言或强制转换 - 不要在中间件外直接调用
r.Context().Value(...)—— 应该封装成GetXXX函数，便于后续替换实现（比如改用结构体字段） - 如果值是结构体，确保它是不可变的；若需修改，请用指针 + 同步控制，但通常不建议
多个中间件写同一个 key 会覆盖吗？如何避免冲突
会覆盖。context 是单向链表结构，WithValue 总是在链头插入新节点，后写的同 key 值会遮蔽前面的。
- 每个中间件应使用**唯一 key 类型**，比如
auth.UserIDKey、trace.TraceIDKey - 避免“通用 key”如
"data"、"config"—— 这类 key 在大型项目中几乎必然冲突 - 如果确实需要聚合数据，建议用结构体承载多个字段，再以单一 key 存入，而不是分散写多个 key
例如：
type RequestContext struct {
UserID int64
TraceID string
TenantID string
}
ctx = context.WithValue(req.Context(), RequestContextKey, &RequestContext{...})
为什么不能把 context 存到全局 map 或 goroutine local storage
因为 HTTP handler 可能被并发调用，且 Go 的 http.Server 默认复用 goroutine（通过 runtime.Gosched 或 channel 协作调度），没有稳定的“goroutine 生命周期”可绑定上下文。
- 全局 map 会导致不同请求间数据污染，尤其在中间件异步操作（如
go func(){}()）时极易出错 - 第三方库如
golang.org/x/net/context（已废弃）或某些 “context local storage” 封装，本质仍是基于req.Context()，只是加了语法糖 - 唯一可靠的数据归属边界就是
*http.Request自带的 context —— 它随请求创建而诞生，随响应结束而释放
真正容易被忽略的是：日志中间件、panic 恢复中间件、超时中间件都依赖 context 生命周期一致性。一旦绕过它，trace ID 就对不上，错误日志就找不到源头。
