是，整个请求生命周期内所有中间件和handler共享同一个*gin.Context实例，其值可通过c.Set()/c.Get()跨中间件传递，但仅限单次请求，响应结束后被重置；goroutine中需显式拷贝数据，禁用c.Value()或重复读c.Request.Body。
中间件链中 *gin.Context 是同一个实例吗
是，整个请求生命周期内所有中间件和最终 handler 拿到的都是同一个 *gin.Context 指针。Gin 不会为每层中间件创建新 Context，而是复用并顺序调用 c.Next() 推进流程。这意味着你在第 1 层中间件里 c.Set("user", u)，第 3 层中间件里 c.Get("user") 能拿到它——前提是没被后续中间件覆盖或清空。
c.Set() 存的值能跨中间件读取，但不能跨请求
值确实能在同一次请求的多层中间件间传递，但必须注意：这些值只存活到 c.Next() 返回、响应写完、Gin 调用 context.Reset() 的那一刻。之后该 *gin.Context 实例会被归还给 sync.Pool，字段（包括 c.Keys）全部清零。下一次请求可能复用同一块内存，但里面的数据早已无效。
- 不要把
&User{}这种栈上临时指针塞进c.Set()，handler 返回后指针就悬空 - 推荐存值类型：
c.Set("user", User{ID: 123})，或指向全局/长生命周期对象的指针（如config.DB） - 键名建议用自定义类型（
type userKey struct{}），避免字符串冲突
goroutine 中直接用 c.Value() 很危险
如果在中间件或 handler 里启了 goroutine，并在里面直接调用 c.Value() 或访问 c.Request.Body，大概率出问题。因为主流程响应一结束，c 就被重置或复用，goroutine 里看到的可能是脏数据、nil、已关闭的 Body，甚至触发 context canceled 错误。
- 正确做法：启动 goroutine 前，把需要的数据显式拷贝出来，比如
u := c.MustGet("user").(User)，再传给 goroutine - 别依赖
c.Request.Context()的 Done channel 在 goroutine 里做取消判断——它的生命周期由 HTTP 请求控制，不是你 goroutine 的生命周期 - 尤其注意：
c.Request.Body在读取一次后就不可重放，子 goroutine 再读会得到空或 error
为什么不要用 context.WithValue 包一层再传
Gin 的 *gin.Context 本身已经嵌套了标准 context.Context（来自 c.Request.Context()），额外套一层 context.WithValue(c.Request.Context(), key, val) 没有收益，反而增加 GC 压力、混淆数据来源，且绕过了 c.Set() 的统一管理逻辑。
- 业务侧传值统一走
c.Set()/c.Get() -
c.Request.Context()应仅用于超时、取消等与请求生命周期强绑定的场景（如超时中间件里调用context.WithTimeout） - 混合使用
c.Set()和context.WithValue()容易导致数据散落、排查困难
c.Value() 的组合，往往在线上压测或高并发时才突然暴露 panic 或数据错乱。 
