直接用 go func() 会出 context canceled 错误，因为 c.request.context() 生命周期仅限 handler 执行期间，handler 返回后 context 被取消，导致后台 goroutine 中的 gorm、http client 等操作失败；安全做法是提前提取并拷贝所需参数，使用 context.background() 配合超时控制，并通过 sync.waitgroup 实现优雅退出。
为什么直接用 go func() 会出 context canceled 错误
因为 c.Request.Context() 的生命周期只到 handler 函数返回为止。一旦响应写完、handler 退出，Gin 就会取消这个 context，所有还在用它的 goroutine 都会立刻收到 context.Canceled。你看到的 GORM 报错、HTTP client 被中断、日志没写完，根源都在这儿。
这不是 Gin 的 bug，是 Go context 设计的本意：它绑定请求生命周期，不该被“拖长”。但很多人没意识到自己写的 goroutine 正在偷偷续命。
- 错误写法：
go func() { db.WithContext(c.Request.Context()).Save(...) } - 后果：5 秒后可能 panic 或静默失败，日志里只有
context canceled - 更隐蔽的问题：goroutine 持有
*gin.Context本身（比如调c.GetString()），handler 一退，c就失效，读取可能返回脏数据或 panic
如何安全提取参数并启动后台协程
核心原则：所有需要的数据，必须在 go 语句之前完成提取和拷贝。不要传 *gin.Context，只传纯值（string/int/struct 等）。
示例中提取 taskID 和 payload 是安全的，但要注意：
-
c.MustGet("payload")返回的是 interface{}，需断言为具体类型并深拷贝（如 struct 值类型自动拷贝，map/slice 需手动 copy） - 避免使用
c.Param()、c.PostForm()等方法在 goroutine 内调用 —— 它们依赖已失效的http.Request - 如果 payload 很大，考虑只传 ID，让后台任务重新查库，而不是把整个结构体塞进 goroutine
给后台协程加超时和 cancel 控制
裸奔的 goroutine 既难调试又易泄漏。哪怕不依赖请求 context，也该有自己的生命周期管理。
推荐用 context.WithTimeout 包一层：
go func(taskID string, payload Payload) {
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
err := syncDataWithRemoteServer(ctx, taskID, payload)
if err != nil {
log.Printf("Background sync failed: %v", err)
}
}(taskID, payload)
-
context.Background()是安全起点，不受请求结束影响 - 超时时间按任务性质设（API 调用建议 10–30s，DB 写入可稍长）
- 务必
defer cancel()，否则 context 泄漏会累积内存 - 若任务本身支持 context（如
db.WithContext(ctx).Save()），就传进去；否则忽略
服务关闭时如何等后台任务收尾
优雅退出不只是停 HTTP server，还得等正在跑的后台任务自然结束（或强制超时）。否则 kill -SIGTERM 后，goroutine 可能被 OS 强杀，留下脏数据。
简单方案：用 sync.WaitGroup 计数 + 全局 channel 通知：
var wg sync.WaitGroup
done := make(chan struct{})
// 启动时
go func() {
- 别用全局变量存 wg —— 改成闭包捕获或注入到 handler 里更可控
- WaitGroup 不解决超时问题，所以要搭配前面的
context.WithTimeout - 真正复杂的场景（大量并发任务），建议用 worker pool + job queue，而不是满天飞的 goroutine
最常被忽略的一点：没有统一的 goroutine 生命周期管理机制，靠人肉加 defer wg.Done() 容易漏。一旦漏掉，wg.Wait() 就永远卡住。
