因为 gin.Context 非线程安全且生命周期绑定 HTTP 请求，handler 返回后即被回收，直接在 goroutine 中使用会导致 panic；正确做法是调用 c.Copy() 获取只读副本，或提前提取必要字段传入 goroutine。
为什么不能直接在 goroutine 里用 c？
因为 gin.Context 不是线程安全的，且生命周期绑定到当前 HTTP 请求 goroutine。一旦 handler 函数返回、响应写出，Gin 就会回收该上下文——后续在异步 goroutine 中访问 c.Request、c.JSON() 或任何字段，大概率 panic：panic: runtime error: invalid memory address or nil pointer dereference。
常见错误写法：
go func() {
time.Sleep(2 * time.Second)
c.JSON(200, gin.H{"msg": "done"}) // ❌ 崩溃：c 已失效
}()正确做法只有一条：必须调用 c.Copy()，它会深拷贝请求头、查询参数、表单数据等只读字段，但剥离响应写入能力（所以你不能在异步 goroutine 里调用 c.JSON()）。
-
c.Copy()后的副本只能读，不能写响应 - 副本不包含原始上下文的
Writer，也不参与中间件链 - 如果需要传递额外数据（如用户 ID），建议提前提取并作为参数传入 goroutine
c.Copy() 之后还能访问哪些字段？
c.Copy() 生成的上下文副本保留了以下常用只读字段，适合做日志、消息通知、统计等非响应类操作：
立即学习“go语言免费学习笔记（深入）”；
-
cCp.Request.URL.Path、cCp.Request.Method -
cCp.Param("id")、cCp.Query("page")、cCp.PostForm("name") -
cCp.Value("user_id")（如果上层中间件已通过c.Set("user_id", id)设置） -
cCp.GetBool("is_admin")等类型安全取值方法
但以下操作会出错或无效：
-
cCp.JSON(200, ...)→ panic（无 Writer） -
cCp.Next()→ 无意义（不走中间件链） -
cCp.Abort()→ 无效（副本不参与请求生命周期）
异步任务里怎么安全传参和记录日志？
别依赖上下文副本传递动态业务数据，尤其不要在 goroutine 闭包里捕获循环变量（如 for _, item := range list 中直接用 item）——容易所有 goroutine 都拿到最后一个值。
推荐写法：
userID := c.GetString("user_id") // 提前提取
taskType := c.Query("type")
gofunc(uid, typ string) {
// 显式传参，避免闭包陷阱
log.Printf("[async] user %s triggered %s task", uid, typ)
// ... 耗时操作：发邮件、写 Kafka、更新统计表
}(userID, taskType)日志本身也需注意：别用 log.Println() 直接打，它同步加锁，在高并发下会成为瓶颈。生产环境应走异步日志库（如 zap.NewAsyncCore()），或至少用带缓冲 channel + 单 worker 模式。
哪些场景适合用 goroutine 异步，哪些不该碰？
适合异步的典型非核心路径：
- 发送站内信、短信、邮件（失败可重试，不阻塞主流程）
- 上报埋点、统计 PV/UV（允许少量丢失）
- 清理临时文件、过期缓存（延迟执行无感知）
- 调用低优先级第三方 API（如天气、汇率，超时可忽略）
绝对不能异步的：
- 影响响应结果的 DB 写入（如订单创建后扣库存）
- 需要返回错误给前端的校验逻辑（如实名认证结果）
- 涉及事务一致性操作（异步脱离事务上下文，极易数据不一致）
- 依赖请求上下文状态变更的操作（如修改
c.Writer状态码）
真正难的不是起 goroutine，而是判断“这件事到底能不能扔出去”。多数线上事故，都源于把本该同步确认的逻辑，当成可丢弃的后台任务处理了。
