gin.Context 不能并发写入，因其 Keys 字段为非并发安全的 map[string]interface{}，多 goroutine 调用 c.Set 或首次 c.Get 会触发 concurrent map writes panic；应改用 sync.Map、带锁结构体或 context.WithValue 等线程安全方案。
为什么 gin.Context 不能并发写入
因为 gin.Context 内部持有 map[string]interface{} 类型的 Keys 字段（用于 Set/Get），而 Go 原生 map 非并发安全。一旦多个 goroutine 同时调用 c.Set("key", val) 或 c.Get("key")（后者在首次访问未初始化的 Keys 时也会触发写入），就会触发 panic：fatal error: concurrent map writes。
c.Set() 和 c.MustGet() 在并发场景下的风险点
常见误用场景包括：中间件中异步启动 goroutine 并试图修改上下文、使用 go func() { c.Set(...) }()、或在 HTTP handler 里调用第三方异步服务后回调中写入 c.Set。这些都会绕过 Gin 的请求生命周期管理，导致上下文被多线程访问。
-
c.Set是非线程安全写操作，永远不要在 goroutine 中调用 -
c.MustGet本身只读，但若此前从未调用过c.Get或c.Set，首次访问会 lazy-initializec.Keys—— 这个初始化是写操作，同样不安全 - 即使只读，如果多个 goroutine 同时首次调用
c.Get，仍可能触发并发写（Go map 初始化不是原子的）
安全替代方案：用 sync.Map 或显式锁封装上下文数据
不要把业务状态塞进 gin.Context，尤其当涉及并发逻辑。正确做法是将需要跨 goroutine 共享的数据抽离出来，独立管理：
- 对简单键值，改用
sync.Map：声明为var sharedData sync.Map，用sharedData.Store("reqID", c.Value("reqID"))存储，sharedData.Load("reqID")读取 - 对结构化数据，定义带
sync.RWMutex的结构体，所有读写加锁 - 若必须传递请求级数据给子 goroutine，用
context.WithValue构造新 context（注意：该 context 是只读的，且不可写回原gin.Context） - 避免在中间件中启动 goroutine；如需异步处理，用 channel + 主 goroutine 收集结果，而非让子 goroutine 直接操作
c
Gin 官方推荐的上下文使用边界
Gin 的 gin.Context 设计初衷是单 goroutine 生命周期内使用（即一个 HTTP 请求对应一个 goroutine）。它的 Set/Get 仅保证该 goroutine 内安全，不提供跨 goroutine 保证 —— 这不是 bug，是明确的设计约束。
立即学习“go语言免费学习笔记（深入）”；
- 所有中间件、handler 函数体内的代码都运行在同一个 goroutine 中，此时
c.Set安全 - 一旦你用
go启动新协程，就脱离了这个安全边界 - 日志中间件中打印
c.Keys是安全的，但前提是没其他 goroutine 正在写它
真正容易被忽略的是：哪怕你没显式写 go，某些第三方库（比如某些异步 validator、prometheus 指标上报 hook）也可能悄悄启 goroutine 并尝试写 c —— 这类依赖要重点审查。
