直接在goroutine中使用c.Request.Context()会出错，因其绑定HTTP请求生命周期，响应结束后即被取消，导致db.WithContext()等调用返回context canceled错误；必须用context.WithTimeout或WithCancel派生新Context并自行管理生命周期。
为什么直接在goroutine里用c.Request.Context()会出错
因为c.Request.Context()绑定的是HTTP请求生命周期，Gin在响应写完、连接关闭后就会取消它。你开的goroutine如果还没执行完，再调用db.WithContext()或http.NewRequestWithContext()，就会立刻收到context canceled错误——不是“偶尔失败”，而是只要请求结束得比goroutine快，就必现。
典型表现：日志没写进数据库、异步通知没发出去、GORM报error: context canceled但handler已返回200。
- 错误不是随机的，和请求耗时、网络延迟、goroutine启动时机强相关
-
c.Copy()不能解决这个问题：它复制的是*gin.Context结构体，但底层Request.Context()仍是同一个 - 哪怕加了
time.Sleep(1 * time.Second)测试能取到参数，也只是掩盖问题——真正上线后高并发下仍会崩
用context.WithTimeout()或context.WithCancel()派生新Context
必须脱离原始请求上下文，自己控制生命周期。关键不是“换个context”，而是“谁来cancel”。
- 不要用
context.Background()——它永不取消，goroutine可能永远挂住 - 推荐用
context.WithTimeout(context.Background(), 30*time.Second)，超时自动清理，适合大多数异步任务（如日志落库、消息推送） - 如果需要手动终止（比如用户取消操作），用
ctx, cancel := context.WithCancel(context.Background())，并在任务完成或异常时显式调用cancel() - 务必在启动goroutine的作用域内
defer cancel()，否则ctx永远不会关闭，等于换了个方式泄漏
示例：
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
defer cancel()
go func(ctx context.Context) {
db := models.GetDB().WithContext(ctx)
db.Model(&Log{}).Where("id = ?", logId).Updates(...)
}(ctx)
中间件里起goroutine必须提取字段，别依赖c.Copy()
c.Copy()深拷贝开销大，且仍共享Request.Context()；更危险的是，它复制了未解析完的form或body，导致后续c.ShouldBind()或c.PostForm报multipart: NextPart: EOF。
- 只提取你需要的值：如
c.ClientIP()、c.Request.Method、c.Request.URL.Path、c.Param("id") - 字符串、数字、时间等基本类型直接传参，避免闭包捕获整个
*gin.Context - 如果必须传结构体，确保它不含指针或未导出字段，否则可能意外延长内存生命周期
错误写法：
go func() {
token := c.DefaultQuery("token", "") // 可能panic或读脏数据
}()
正确写法：
token := c.DefaultQuery("token", "")
ip := c.ClientIP()
go func(t, ip string) {
// 用t和ip，不碰c
}(token, ip)
GORM操作前确认Context是否已取消
即使你用了新Context，GORM调用链深处仍可能因I/O阻塞而错过取消信号。别假设db.WithContext(ctx)就万事大吉。
- 在关键操作前加
select判断：if err := ctx.Err(); err != nil { return err } - 对长耗时查询（如JOIN多表、大结果集Scan），在循环中定期检查
ctx.Err() - 避免在goroutine里复用全局
*gorm.DB实例的WithContext()结果——每次调用都应基于当前有效ctx新建操作句柄
尤其注意db.Transaction()：事务内所有操作共享同一Context，一旦超时，整个事务会回滚，但错误可能被静默吞掉。
最易被忽略的一点：Context取消后，底层TCP连接未必立刻断开，GORM可能还在尝试重试或等待网络响应——这会导致goroutine卡在runtime.gopark状态，pprof里看得到但查不到源头。
