结论：在Gin中启动协程时，绝不能直接用c.Request.Context()做超时控制，必须用context.WithTimeout或context.WithCancel创建新context，并确保cancel()被调用；因为HTTP请求一结束，Gin会自动取消该context，导致绑定它的协程收到context canceled错误，使数据库更新、消息推送等异步任务静默失败。
直接说结论：在 Gin 中启动协程时，绝不能直接用 c.Request.Context() 做超时控制，必须用 context.WithTimeout 或 context.WithCancel 创建新 context，并确保 cancel() 被调用。
为什么直接传 c.Request.Context() 会出 context canceled 错误
HTTP 请求一结束，Gin 就会自动调用 cancel() 取消 c.Request.Context()。而你开的协程如果还在用这个 context（比如传给 GORM、HTTP client 或自己监听 ctx.Done()），就会立刻收到取消信号——哪怕主接口早已返回成功。这不是 bug，是 Gin 的正常行为。
- 现象：日志里频繁出现
context canceled，但用户无感知，数据库更新/消息推送静默失败 - 本质：协程生命周期脱离了请求生命周期，却还绑着请求的 context
- 典型场景：异步写日志、发通知、调第三方 API、FFmpeg 处理视频等耗时操作
context.WithTimeout 的正确用法和常见错例
必须显式创建带超时的新 context，并在协程退出前调用 cancel()。否则可能泄漏 goroutine 或资源句柄（如数据库连接）。
- ✅ 正确写法：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)—— 父 context 用context.Background()，不是c.Request.Context() - ❌ 错误写法：
ctx, cancel := context.WithTimeout(c.Request.Context(), 5*time.Second)—— 子 context 继承了父 context 的“短命”属性，仍会被请求结束触发取消 - ⚠️ 忘记
defer cancel()或没在协程退出路径上显式调用cancel()，会导致 context 泄漏，Done()channel 永不关闭 - 示例片段：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() // 主协程退出时清理 go func() { defer cancel() // 协程完成时也清理（双重保险） // ... 执行耗时操作 }()
Gin 中协程超时后如何安全处理结果
不能只靠 阻塞等待，必须配合 <code>select 和错误判断，否则会丢失执行结果或 panic。
- 监听
ctx.Done()时，必须用select，不能直接—— 否则无法同时获取操作结果 - 超时后检查
ctx.Err()：等于context.DeadlineExceeded表示真超时；等于context.Canceled可能是手动 cancel 或父 context 提前结束 - GORM 场景下，别把
db.WithContext(ctx)和超时 context 混用：超时 context 应仅用于控制协程生命周期，DB 操作本身应有自己的重试或 fallback 逻辑 - 示例判断：
select { case <-doneCh: // 正常完成 case <-ctx.Done(): if errors.Is(ctx.Err(), context.DeadlineExceeded) { log.Warn("task timeout") } }
最易被忽略的点：超时 context 的父 context 必须是 context.Background() 或一个长期存活的 context（如服务启动时创建的 root context），而不是任何与 HTTP 请求绑定的 context。协程一旦脱离请求上下文，它的生命周期就该由你自己定义和终结。
