Gin的c.Request.Context()被自动取消是因为其设计将Context生命周期严格绑定HTTP请求，请求结束（响应写出、客户端断开或超时）时Gin自动调用cancel()关闭Done通道，这是正常协作式退出机制，而非bug；“野生协程”直接使用该Context会导致异步任务因context.Canceled而中断，应改用context.WithoutCancel或独立Context解耦。
为什么Gin的c.Request.Context()会被自动取消
Gin在HTTP请求结束（客户端断开、超时、响应写出完成）时，会主动调用cancel()函数关闭c.Request.Context()的Done()通道。这不是bug，而是设计行为：每个HTTP请求的生命周期天然对应一个context，一旦请求上下文失效，所有依赖它的操作（如数据库查询、下游HTTP调用）理应感知并退出。
常见误判是把context.Canceled当成错误——它只是信号，不是异常。比如GORM报context canceled，说明它收到了取消信号并提前终止了SQL执行，属于正常协作式退出。
- 客户端在浏览器关掉页面、Postman点Cancel、curl加
--max-time后中断，都会触发Gin cancel - 即使你没显式调
cancel()，Gin内部已封装好，在WriteHeader或连接关闭时自动触发 -
c.Request.Context()和context.Background()完全无关，不能互相替换
goroutine里直接用c.Request.Context()就踩坑
“野生协程”最典型的问题：在go func()里直接捕获c.Request.Context()，却没意识到这个context随时会失效。请求一返回，协程还在跑，但ctx.Err()立刻变成context.Canceled，后续的db.WithContext(ctx)或http.NewRequestWithContext全会失败。
- 错误写法：
go func() { db.WithContext(c.Request.Context()).Save(&u) }() - 正确做法：用
context.WithoutCancel(c.Request.Context())（Go 1.21+）或context.Background()新建独立context，再传入必要值（如trace ID） - 更稳妥的是彻底解耦：把异步任务扔进消息队列，或用
sync.WaitGroup+ 独立context控制生命周期
如何验证你的代码真正在监听ctx.Done()
光有if ctx.Err() != nil不够——它只检查一次。真正有效的监听必须在阻塞点或循环中持续响应，否则取消信号永远收不到。
- HTTP请求：必须用
http.NewRequestWithContext(ctx, ...)，手动赋值req.Context = ctx无效 - 数据库操作：GORM v1.25+支持
db.WithContext(ctx)，但需确认底层驱动（如pgx）真正监听了context；旧版GORM不监听，WithContext只是透传 - 自定义循环：必须用
select而非if，且case 要作为独立分支，不能被其它永远可读的case挡住 - 调试技巧：在goroutine开头打印
fmt.Printf("ctx err: %v\n", ctx.Err())，父级cancel后这里应立刻输出context.Canceled
别在defer里依赖context状态
很多人写defer func() { if ctx.Err() == context.Canceled { log.Warn("canceled") } }()，这很危险——cancel可能发生在defer执行前，此时ctx.Err()已为context.Canceled，但业务逻辑还没清理完，导致panic（比如往已close的channel写日志）。
- defer里只做确定安全的操作：关闭文件句柄、释放内存、解锁mutex
- 资源清理逻辑必须和取消信号同步：在
case 分支里显式执行 - 如果必须记录取消原因，用
ctx.Err()的值，而不是靠defer延迟判断
context取消不是魔法开关，它只发信号；谁来听、怎么停、停多快，全由你写的代码决定。最容易被忽略的，是那些没被select包裹的阻塞调用，比如time.Sleep或第三方库的无context接口——它们根本收不到信号。
