不能将 *gin.Context 当普通指针传给 goroutine，因其非线程安全，内部含可变状态（Values/Request/Writer），并发读写易致 panic 或数据错乱；须用 ctx.Copy() 创建只读副本，写响应需通过 channel 由主 goroutine 统一处理。
为什么不能把 \*gin.Context 当普通指针传给 goroutine
因为 \*gin.Context 不是线程安全的，内部包含可变状态（如 Values、Request、Writer），一旦在 goroutine 中读写，可能触发 panic 或数据错乱。常见错误现象是：程序偶发 panic: runtime error: invalid memory address，或日志里出现 http: response.WriteHeader on hijacked connection。
典型误用场景：go handleAsync(ctx)，其中 handleAsync 直接用了传入的 ctx 做 ctx.JSON() 或 ctx.Set()。
- 必须用
ctx.Copy()创建副本，且仅限读操作（如取ctx.Value()、ctx.Param()） - 若需写响应，改用 channel + 主 goroutine 统一处理，不要在子 goroutine 里碰
ctx.Writer -
ctx.Copy()不复制底层http.ResponseWriter，所以它只适合「只读上下文」场景
ctx.Value() 存指针值时要注意生命周期
很多人习惯往 ctx.Value() 里塞结构体指针（比如 &User{ID: 123}），但容易忽略：这个指针指向的内存是否在请求结束后还有效？Gin 的 \*gin.Context 生命周期只到 handler 返回为止，之后整个对象可能被复用或回收。
- 存原始值（
int、string）最安全；存结构体建议用值类型，避免裸指针 - 若必须存指针（例如共享配置或 DB 实例），确保它来自全局变量或长生命周期对象，而非 handler 内部临时分配
- 别用
ctx.Value()传 request body 解析结果——应提前解析好再存，否则子 goroutine 可能读到nil或已关闭的Body
用 context.WithValue() 替换 ctx.Set() 的实际代价
ctx.Set() 是 Gin 自定义方法，底层其实也是调用 context.WithValue()，但它把 key 强制转成 string，导致类型不安全、易冲突。而原生 context.WithValue() 要求 key 是接口或指针类型，更可控。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐定义私有 key 类型：
type ctxKey string; const userKey ctxKey = "user"，避免字符串 key 冲突 - 每次
context.WithValue()都会新建一个 context 实例，链路越深，嵌套越深，性能开销略增（但对 Web 请求影响微乎其微） - Gin 的
ctx.Set()/ctx.Get()在并发读写时无锁保护，而context.WithValue()构建的是不可变链表，天然线程安全
跨中间件传递指针数据的正确姿势
想在中间件 A 中解析用户信息，让后续 handler 和中间件 B 都能拿到，不能直接 ctx.Set("user", &u) 然后期望别处安全使用该指针。
- 中间件中解析后，用
ctx = context.WithValue(ctx, userKey, u)（传值，非指针） - handler 中用
u, ok := ctx.Value(userKey).(User)断言，不是*User - 如果结构体很大，担心拷贝开销，可定义全局 map + request ID 做缓存，但得配清理逻辑（比如用
ctx.Done()触发回收）
复杂点在于：Context 的 value 链是单向不可变的，你没法“更新”已设的 key，只能不断包裹新 context。所以别指望在 handler 里改完 User 再透传回去——那需要上层中间件主动接收并重 wrap。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
