在 Gin 中应使用 c.Set() 而非 context.WithValue() 存值，因前者专为请求生命周期设计；c.Get() 需双返回值判断类型与存在性，且值不会自动透传至下游 HTTP 请求头，须手动注入；禁止在 context 中存大结构体或指针以防内存泄漏。
在中间件里用 c.Set() 存值，不是 context.WithValue()
很多人一看到“上下文传递”就直奔标准库的 context.WithValue()，但在 Gin 里这是低效且易出错的做法。Gin 的 *gin.Context 自带键值存储（Keys map[string]interface{}），专为请求生命周期内跨中间件/处理器传参设计。c.Set("user_id", "123") 是最直接、最安全的方式；而手动操作底层 req.Context() 不仅冗余，还容易漏掉 c.Request = req.WithContext(newCtx) 这步，导致下游拿不到。
下游 HTTP 请求必须手动注入请求头，c.Get("key") 不会自动透传
你在中间件里存了 c.Set("trace_id", "abc123")，这只是让当前请求的后续 handler 能取到——它不会自动出现在发给其他服务的 HTTP 请求头里。要实现跨服务传递，必须在调用下游 API 前显式读取并写入：
- 用
c.Get("trace_id")取值（注意返回interface{}，需类型断言） - 构造
http.Client请求时，调用req.Header.Set("X-Request-ID", traceID) - 别依赖
http.DefaultClient自动继承，它完全不感知*gin.Context
c.Get() 返回的是 interface{}，类型断言失败是常见 panic 点
直接写 userID := c.Get("user_id").(string) 很危险：如果 key 不存在或存的是 int，运行时直接 panic。正确做法是始终用双返回值判断：
userID, exists := c.Get("user_id")
if !exists {
c.JSON(http.StatusUnauthorized, gin.H{"error": "missing user context"})
c.Abort()
return
}
idStr, ok := userID.(string)
if !ok {
c.JSON(http.StatusInternalServerError, gin.H{"error": "invalid user_id type"})
c.Abort()
return
}
尤其要注意中间件执行顺序：如果某个中间件没 set 就 abort 了，后续 handler 调 c.Get() 必然不存在。
不要在 context.WithValue() 里塞结构体或指针
虽然技术上可行，但 Gin 的 *gin.Context 生命周期只覆盖单次 HTTP 请求，所有数据都在内存池中复用。若往底层 context.Context 里塞大结构体、切片或未清理的指针，可能引发内存泄漏或脏数据残留。官方明确建议：只用 c.Set() 存轻量标识（如 ID、token 字符串），业务实体该走参数就走参数，该走 DB 就查 DB。
