不能直接往*gin.context结构体加字段，因其由sync.pool动态复用、请求结束即重置归还；必须使用c.set()/c.get()等内置键值存储机制安全传递数据。
直接用 c.Set() 写入，后续用 c.MustGet() 或 c.Get() 读取——这是 Gin 中扩充请求上下文最常用、也最安全的方式。
为什么不能直接往 *gin.Context 结构体里加字段？
Gin 的 gin.Context 是运行时动态构建的，底层由 sync.Pool 复用，每次请求结束就会被重置归还。你无法在结构体定义层面扩展字段，硬改源码或嵌套结构只会破坏生命周期管理，导致 panic 或数据残留。
正确路径只有一条：利用它内置的键值存储机制。
-
c.Set("user_id", 123)写入任意类型值（支持 interface{}） -
val, ok := c.Get("user_id")安全读取，返回interface{}和 bool -
uid := c.MustGet("user_id").(int)强制断言（panic 风险高，仅限确定存在且类型明确时）
c.Set() 的键名要注意什么？
键名是字符串，但实际底层用 map[interface{}]interface{} 存储，所以理论上支持任意类型键。不过 Gin 官方示例和社区惯例都用 string，原因很实在：
- string 键便于调试和日志输出（比如打印整个 context map）
- 避免因不同包用不同类型键导致“同名不同键”的覆盖问题
- 中间件之间传递上下文时，string 键更易约定和文档化（如
"auth_user"、"request_id"）
别用数字或 struct 作键——不是不能，而是没人这么干，协作成本高。
什么时候该用 c.Set()，什么时候该用中间件参数传入？
c.Set() 解决的是「请求生命周期内跨中间件/处理器共享数据」的问题；而闭包式中间件（如 func(role string) gin.HandlerFunc）解决的是「中间件初始化配置复用」问题。两者不冲突，但目的不同：
- 用户角色、权限信息、解析后的 JWT payload → 用
c.Set()注入到 context，下游所有 handler 都能取 - 日志前缀、模块标识、限流阈值 → 用闭包中间件传参，在中间件内部决定怎么用这些配置
- 千万别把配置参数塞进
c.Set()当全局变量用——那会污染每个请求的上下文，且无法区分不同路由的配置差异
并发场景下写入 c.Set() 安全吗？
安全，但有前提：必须在主 goroutine 中调用。Gin 的 gin.Context 不是并发安全的，它的 map 存储没加锁。如果你在中间件里启了 goroutine，并试图在 goroutine 里调用 c.Set()，会出现 panic 或数据丢失。
正确做法是：
- 需要异步处理的数据，先用
c.Copy()拷贝 context，再在 goroutine 里对副本操作（c.Copy()返回的新 context 可以安全 Set） - 主流程中完成所有
c.Set()，确保下游 handler 拿到的是完整上下文 - 不要依赖 goroutine 中的
c.Set()结果去影响主流程响应逻辑
最容易被忽略的点：c.Copy() 只拷贝了基础字段（Request、Writer 等），但不会复制已通过 c.Set() 写入的键值对——所以想让副本也有初始上下文，得手动 copyCtx.Set(...)。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
