不能在 goroutine 中直接使用 *gin.context，因其生命周期仅限 handler 执行期，主协程返回后 context 被复用或回收，导致读取参数、header 或写日志时 panic；必须提前提取纯数据（如字符串、结构体副本）传入 goroutine。
直接在 Gin handler 里 go func() {}() 是最常见也最容易出错的做法——不是不能用，而是不加隔离地用，*gin.Context 会立刻失效，后续读取 c.Param()、c.GetHeader() 或写日志都可能 panic。
为什么不能在 goroutine 中直接使用 *gin.Context
Gin 的 *gin.Context 是 request-scoped 对象，底层绑定着 http.ResponseWriter 和 *http.Request。handler 函数一返回，Gin 就会回收或复用这些资源。goroutine 若此时还试图调用 c.MustGet("user_id") 或 c.PostForm("file")，轻则返回空值或脏数据，重则直接 panic。
这不是“偶尔出问题”，而是确定性行为：只要主协程退出，c 就不可靠。
- 错误示例：
go func() { log.Println(c.GetString("trace_id")) }()——c是闭包捕获，但已失效 - 正确做法：所有需要的数据，必须在
go前提取为独立变量（字符串、int、结构体副本等） - 特别注意：
c.Copy()并不安全——它只复制键值对和错误列表，不复制底层Request或ResponseWriter，仍会 panic
go func() {}() 该传什么参数
启动 goroutine 时，只传「纯数据」，不传任何带生命周期依赖的对象。核心原则：传进去的每个值，都要能在 handler 返回后独立存活。
- ✅ 安全传入：
userID := c.GetString("user_id")→ 传userID字符串 - ✅ 安全传入：
payload := parsePayload(c)→ 传payload结构体副本（非指针，或确保深拷贝） - ✅ 安全传入：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)→ 传ctx，并记得defer cancel() - ❌ 危险传入：
c、&c、c.Request、c.Keys、c.Errors
如果任务需超时控制或可取消，务必用 context.WithTimeout 或 context.WithCancel 新建上下文，而不是复用 c.Request.Context() —— 后者随 HTTP 请求结束而 cancel，会导致后台任务提前中止。
如何避免 goroutine 泄漏和静默失败
裸起 goroutine 最大的风险不是立即 crash，而是泄漏和失败无感知：HTTP 响应发出去了，但后台任务卡死、连接没关、错误被吞掉。
- HTTP client 必须设超时：
http.Client{Timeout: 10 * time.Second}，否则一次失败请求可能 hang 住整个 goroutine - 数据库操作要配
context.WithTimeout，防止事务长期占用连接池 - 所有错误必须显式处理：
if err != nil { log.Printf("sync failed: %v", err) }，不能只写if err != nil { return } - 避免无限重试逻辑；若需重试，用带最大次数和退避的循环，而非
for {}
尤其注意 RabbitMQ 或 Kafka 生产者：不要在 goroutine 里直接调用 ch.Publish()，而应把消息序列化后丢进带缓冲的 chan []byte，由单独消费者 goroutine 持续发送并重试。
并发多个后台任务时怎么同步
如果一个请求要触发多个独立后台任务（比如同时推送短信 + 写审计日志 + 调第三方 API），用 sync.WaitGroup + 多个 goroutine 是标准解法，但要注意别在 WaitGroup 上阻塞 handler。
- ✅ 正确：每个任务用
go func() { defer wg.Done(); doWork() }()，然后go func() { wg.Wait(); close(doneCh) }()异步等待 - ✅ 更推荐：用
errgroup.Group，自动聚合错误、支持上下文取消 - ❌ 错误：
wg.Wait()放在 handler 主流程里 —— 这就又变成同步阻塞了 - ⚠️ 注意：
WaitGroup的Add()必须在go前调用，且数量固定；动态增删会导致 panic
真正容易被忽略的点是：并发任务之间若共享变量（比如共用一个 map 记录状态），必须加锁或改用 sync.Map，否则 race condition 会在压测时突然爆发。
