不能直接传*gin.context到goroutine中，因其非线程安全且含可变状态；应提前提取所需值或用c.copy()获取只读副本，但不可读body；写响应必须在主goroutine完成；传上下文需用context.withoutcancel并手动注入traceid等关键值。
直接传 *gin.Context 会 panic
不能把 *gin.Context 当普通指针丢进 go func() 里用。它不是线程安全的，内部含可变状态（Values、Request、Writer），子 goroutine 里一读 c.Param() 或写 c.Set()，就可能触发 panic: runtime error: invalid memory address，或者日志里冒出 http: response.WriteHeader on hijacked connection。
只读场景：用 c.Copy() 提取必要字段
c.Copy() 生成一个只读副本，不带底层 http.ResponseWriter，适合取值但不能写响应。但它仍依赖原 *gin.Context 的生命周期——若 handler 已返回，副本里的 Request.Body 可能已关闭，c.PostForm() 会读空或报错。
- ✅ 安全做法：在启动 goroutine 前，把真正需要的值提取出来，比如
c.GetString("user_id")、c.MustGet("payload") - ⚠️ 避免：在 goroutine 里调用
c.ShouldBindJSON()、c.GetRawData()、c.Param()—— 这些都可能访问已失效的Request或Body - ? 注意：
c.Copy()不复制Request.Body，所以即使用了副本，也别指望还能读 body 内容
需要写响应？别在 goroutine 里碰 c.Writer
后台任务如果要发通知、改数据库、调第三方 API，没问题；但想通过 c.JSON() 或 c.String() 回写 HTTP 响应？不行。此时 c.Writer 早已被 Gin 回收或复用，强行写会 panic 或静默失败。
- ✅ 正确路径：用
chan或sync.WaitGroup把结果传回主 goroutine，由 handler 统一处理响应 - ✅ 替代方案：改用消息队列（如 Redis Stream、NATS）或本地任务队列（如 asynq），彻底解耦生命周期
- ❌ 错误示范：
go func() { c.JSON(200, "done") }()—— 这是典型的“野生协程”，大概率 crash
如何保留 traceID、requestID 等上下文元数据
直接用 c.Request.Context() 启动 goroutine 是危险的，因为它的取消信号会随请求结束而触发，导致后台任务被意外中断（比如 GORM 报 context canceled）。但你又需要 traceID 做链路追踪。
- ✅ 推荐组合：
context.WithoutCancel(c.Request.Context())+ 手动注入关键值 - ✅ 示例：
asyncCtx := context.WithValue(context.WithoutCancel(c.Request.Context()), "trace_id", c.GetString("trace_id")) - ⚠️ 注意：
context.WithoutCancel会丢掉父 ctx 的所有Value，必须手动补全，否则链路就断了 - ? 更稳的做法：定义私有 key 类型（如
type ctxKey string），避免字符串 key 冲突
Request.Body 和 Values 里存的指针，它们的生命周期往往比你以为的短得多。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
