不能直接将 *gin.Context 传入 goroutine，因其非线程安全，内部含可变状态（Values/Request/Writer），并发读写易致 panic 或响应 hijacked；须用 ctx.Copy() 创建只读副本，写响应需通过 channel 由主 goroutine 统一处理。
为什么不能直接把 *gin.Context 传进 goroutine
因为 *gin.Context 不是线程安全的，内部字段（比如 Values、Request、Writer）会在 handler 执行过程中被反复读写。一旦多个 goroutine 同时操作同一个 ctx，轻则 panic: runtime error: invalid memory address，重则响应写入被 hijacked（错误信息：http: response.WriteHeader on hijacked connection）。
典型误用：
- 在 goroutine 里调用 ctx.JSON()、ctx.Set() 或修改 ctx.Request
- 把 ctx 当作普通指针传给异步函数，比如 go handle(ctx)
根本原因不是“不能传”，而是“传了之后你敢不敢碰它”——只要子 goroutine 一碰 Writer 或往 Values 写，就大概率崩。
ctx.Copy() 做了什么、又没做什么
ctx.Copy() 创建的是一个「只读副本」：它复制了 Params、Keys、Request 等字段，但把 ResponseWriter 设为 nil，并清空 handlers 和中断索引。这意味着：
- ✅ 可安全调用
cCp.Param()、cCp.Value("key")、cCp.Query() - ✅ 可读
cCp.Request.URL、cCp.Request.Header.Get("X-ID") - ❌ 不能调用
cCp.JSON()、cCp.String()、cCp.Set()—— 这些会 panic - ❌ 不复制底层
http.ResponseWriter，所以写响应必须绕开它
注意：ctx.Copy() 不克隆请求 body；如果原始 ctx.Request.Body 已被读取或关闭，副本里也是空的。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
需要写响应时，怎么安全地异步处理
子 goroutine 不能碰 ctx.Writer，但业务又常需要“异步做完再回结果”，这时得靠 channel + 主 goroutine 协作：
- 定义结构体承载结果，比如
type Result { Code int; Data any; Err error } - 启动 goroutine 时传入
chan，而不是 <code>*gin.Context - goroutine 完成后发结果到 channel，主 goroutine 用
select或阻塞收，并用原始ctx写响应 - 加超时控制，避免 goroutine 永久阻塞导致 ctx 泄漏
示例关键片段：
ch := make(chan Result, 1)
go func() {
defer close(ch)
// ... 耗时逻辑
ch <- Result{Code: 200, Data: "done"}
}()
select {
case res := <-ch:
ctx.JSON(res.Code, res.Data)
case <-time.After(5 * time.Second):
ctx.JSON(408, gin.H{"error": "timeout"})
}
ctx.Value() 存什么才安全
ctx.Value() 是唯一被 ctx.Copy() 显式深拷贝的键值区，但存什么很关键：
- ✅ 存原始值：
ctx.Value("user_id")是int64或string—— 安全 - ✅ 存结构体值：
ctx.Value("user")是User{ID: 123}—— 复制的是值本身 - ⚠️ 存指针要小心：
ctx.Value("user")是&User{...}—— 若该指针指向 handler 内局部变量，请求结束后内存可能已回收 - ❌ 别存
ctx.Request.Body或未解析完的json.RawMessage—— 副本里还是同一个流，可能已被读过或关闭
真正安全的做法：提前解析好 body，存解析后的结构体或基础类型；若必须存指针，确保它来自全局对象（如配置、DB 实例），而非临时分配。
最易被忽略的一点：即使用了 ctx.Copy()，如果 goroutine 里还去调 ctx.ShouldBindJSON() 或其他触发 ParseForm() 的方法，依然可能并发读 body —— 这些操作不是只读的，它们会修改 Request 内部状态。
