不能用全局变量传递请求数据，因为多个goroutine会互相覆盖；Context才是Gin中协程安全的唯一载体，其生命周期与单次请求绑定，通过c.Set/c.Get实现安全的数据传递与隔离。
不能直接用全局变量传递数据，Context 才是 Gin 里协程安全的唯一载体
为什么不能用 package-level 变量存请求数据
每个 HTTP 请求由独立 goroutine 处理，如果把用户 ID、token 或请求 ID 存在 var userID string 这类包级变量里，多个请求会互相覆盖——这不是竞态，而是逻辑错乱。Go 的 goroutine 调度不保证执行顺序，也没有自动隔离机制。
常见错误现象：
- A 请求写入 currentUser = "alice"，B 请求紧接着写入 currentUser = "bob"，但 A 的 Handler 里读到的却是 "bob"
- 日志里出现混杂的 traceID，无法关联单次请求链路
- 中间件修改了某个全局 map，后续 Handler 读到的是其他请求塞进去的值
根本原因：Go 语言本身不提供“请求作用域”的变量容器，必须靠框架抽象层来补足。
gin.Context 是唯一被设计为协程安全的数据载体
gin.Context 是一个接口，实际类型是 *gin.context，它在每次请求初始化时创建，生命周期与该 goroutine 绑定。所有字段（如 c.Request、c.Writer）都只对该请求可见。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 用 c.Set("key", value) 存自定义数据（比如解析后的 JWT payload）
- 用 c.Get("key") 读取，返回 value, exists bool，避免 panic
- 不要用 c.Keys 直接赋值（它是 map 类型，但 Gin 内部未加锁，不保证并发安全）
- 所有中间件和 Handler 共享同一个 *gin.Context 实例，所以数据天然隔离
示例：
func AuthMiddleware(c *gin.Context) {
token := c.GetHeader("Authorization")
user, err := parseToken(token)
if err != nil {
c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})
return
}
c.Set("user", user) // ✅ 安全写入
c.Next()
}
<p>func ProfileHandler(c <em>gin.Context) {
user, ok := c.Get("user") // ✅ 安全读取
if !ok {
c.AbortWithStatus(403)
return
}
c.JSON(200, gin.H{"name": user.(</em>User).Name})
}
跨中间件传递数据的典型陷阱
容易踩的坑：
- 在中间件里用 defer 修改 context 数据，但 defer 执行时 Handler 已结束，下游拿不到
- 把指针类型（如 *sql.Tx）存进 context 后，在 Handler 里忘记检查是否为 nil
- 使用 c.MustGet("key") 而不是 c.Get("key")，一旦 key 不存在直接 panic（尤其在测试或异常路径下）
- 在异步 goroutine（比如 go func() { ... }()）里访问 c，此时 c 可能已被回收或状态已变
性能影响：
- c.Set 和 c.Get 是 O(1) 操作，底层用 map 实现，但 map 初始化有少量开销
- 频繁 Set/Get 小对象（如 string、int）无压力；但避免塞大结构体或未关闭的资源（如 file handle）
需要持久化或跨请求共享？别硬塞 context
context 生命周期仅限单次请求，如果要存 session、缓存、配置或数据库连接池：
- Session：用 github.com/gorilla/sessions 或 Redis + 自定义 middleware
- 全局配置：启动时加载到 struct，用 sync.Once 初始化，通过依赖注入传给 Handler（不要塞 context）
- DB 连接池：gorm.DB 或 *sql.DB 是线程安全的，应作为全局变量或服务对象持有，Handler 里直接调用方法
- 日志 traceID：用 c.Request.Context().Value()（标准库 context）配合中间件注入，比 c.Set 更符合 Go 生态习惯
最常被忽略的一点：很多人以为 gin.Context 是“万能胶水”，其实它只是请求上下文的快照。真正需要长期存活、跨 goroutine 或跨请求的数据，必须走显式管理——Gin 不替你做这件事，也不该做。
