应使用 Gin 的 c.Set() 和 c.Get() 在中间件间安全传值，因其基于线程安全的 Keys 字段；禁用只读的 c.Request.Header；需在 c.Next() 前调用 c.Set()，检查 c.Get() 的 bool 返回值，键名建议用常量，避免 context.WithValue() 造成冗余和内存泄漏风险。
中间件之间怎么安全传数据？用 c.Set() 和 c.Get()
别碰 c.Request.Header 传值——它只读，写进去的值不会被后续 Handler 读到，因为那是响应头或伪造请求头，不是上下文状态。Gin 的 gin.Context 内置了线程安全的键值存储字段 Keys，专为这个场景设计。
实操要点：
-
c.Set("user_id", 123)必须在调用c.Next()前执行，否则下游拿不到 -
c.Get("user_id")返回interface{}和bool，务必检查第二个返回值，避免 panic - 键名建议用常量定义（如
const KeyUserID = "user_id"），防止拼写错误和类型混乱 - 不推荐用
string以外的类型做 key（比如 struct 或指针），Go map key 要可比较，且 Gin 源码里实际用的是any，但 string 最稳妥
为什么不能用 context.WithValue() 替代 c.Set()？
因为 gin.Context 和 context.Context 是两套东西：gin.Context 是框架封装的 HTTP 处理对象，context.Context 是 Go 标准库用于 goroutine 生命周期和取消信号的接口。前者生命周期绑定单次 HTTP 请求，后者可能跨 goroutine 甚至超出生命周期。
常见误用现象：
立即学习“go语言免费学习笔记（深入）”；
- 在中间件里调用
ctx := context.WithValue(c.Request.Context(), "user", u)，然后期望处理器里用c.Request.Context().Value("user")拿到——能拿到，但绕远、冗余、易混淆 - 把数据库连接、日志实例等长生命周期对象塞进
context.Context，导致内存泄漏风险（虽然 Gin 默认的c.Request.Context()会在请求结束时 cancel，但自定义 value 不会自动清理） -
gin.Context本身已提供更轻量、更语义明确的Set/Get，没必要叠一层
c.Set() 的数据能撑多久？哪些地方会丢？
只要没调用 c.Abort() 或 panic 导致链中断，c.Set() 存的数据会一直保留在当前 gin.Context 实例中，直到该请求生命周期结束（即响应写出、连接关闭）。
容易丢数据的几个坑：
- 在
c.Next()之后再c.Set()—— 后续 Handler 已执行完毕，设了也白设 - 在某个中间件里调用了
c.Abort()，但前面中间件已经c.Set()了，后续 Handler 不会执行，自然读不到；但同个中间件内c.Get()仍有效 - 用
c.Copy()克隆 Context（比如并发打多个下游服务），克隆体里的Keys是深拷贝的 map，但原始c和副本互不影响——这不是 bug，是预期行为，但容易误以为“改了副本会影响主流程”
结构体或复杂数据怎么传？要不要序列化？
直接传指针或结构体就行，Keys 是 map[any]any，支持任意类型。不需要 JSON 序列化，那反而增加开销和出错点。
示例：
// 中间件 A
type UserInfo struct {
ID int64
Role string
Email string
}
c.Set("user_info", &UserInfo{ID: 1001, Role: "admin"})
// 处理器
if v, ok := c.Get("user_info"); ok {
if user, ok := v.(*UserInfo); ok {
// 安全使用
_ = user.Email
}
}
注意：传结构体值（非指针）也可以，但若后续 Handler 需要修改内容并让更下游感知，就得传指针；如果只是只读，传值更安全，避免意外修改影响其他 Handler。
真正复杂的地方在于类型断言链——一旦中间件多了、数据嵌套深了，v.(type) 或连续断言容易出错。这时候建议封装一个 MustGetUser(c *gin.Context) *UserInfo 工具函数，统一处理 panic 和类型校验，而不是每个地方都手写断言。
