结论：不能把 c.Request.Context() 直接传进子协程长期使用，因其生命周期仅限于 HTTP 请求，响应结束即被取消，导致异步 DB 操作中断、context canceled 错误频发；正确做法是用 context.WithTimeout 或 context.WithCancel 显式创建新 context 并管控生命周期。
直接说结论：不能把 c.Request.Context() 直接传进子协程里长期用，更不能用它控制异步数据库操作——这是 context canceled 错误最常见、最隐蔽的来源。
为什么 c.Request.Context() 不能直接传给子协程
因为这个 context 生命周期只活到 HTTP 请求结束。Gin 在 response 写完、连接关闭后会立刻调用 cancel()，所有监听它的 goroutine 都会收到信号退出。你写的 go func() { db.WithContext(c.Request.Context()).Save(...) } 看似没问题，实际只要请求响应了，哪怕数据库还在写，也会被强制中断。
- 现象：日志里频繁出现
context canceled，但 HTTP 接口返回 200 成功 - 本质：子协程没做生命周期隔离，和请求绑死了
- 后果：GORM 操作失败、事务回滚、数据不一致、错误被静默吞掉
正确做法：用 context.WithTimeout 或 context.WithCancel 拷贝并延长生命周期
必须显式拷贝一个新 context，脱离原始请求上下文的控制范围。关键不是“要不要传 context”，而是“传哪个 context”。
- 需要等待结果（比如发邮件后要确认是否成功）→ 用
context.WithTimeout(parent, 5*time.Second)，设合理超时 - 纯后台任务（比如记录审计日志、上报监控）→ 用
context.WithCancel(context.Background())，自己控制取消时机 - 绝对不要：
go func() { ... db.WithContext(c.Request.Context()) ... }() - 推荐写法：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second); defer cancel()
避免“野生协程”的三个硬性约束
所谓“野生”，就是没人管、没超时、没取消、没等待的协程。它们是线上故障的温床。
立即学习“go语言免费学习笔记（深入）”；
- 每个
go func()必须配套sync.WaitGroup或select+Done()等待机制，否则可能 panic 或资源泄漏 - 所有涉及 I/O 的子协程（DB、HTTP Client、文件读写）必须带 context 控制，且不能复用
c.Request.Context() - 如果任务重要（如扣款、发券），别用裸
go func()，改用带重试、持久化、可观测性的任务队列（如 Asynq、BullMQ）
真正难的不是写 go func()，而是想清楚这个协程该活多久、谁来关它、失败了怎么兜底。多数 context canceled 报错，其实暴露的是业务逻辑里对“异步”二字的理解偏差——它不是“扔出去就不管”，而是“换一种方式管”。
