context取消后defer注册的函数不自动执行，因为defer只在函数返回时触发，而context.cancel仅关闭done通道，资源清理需显式响应取消信号并手动释放。
Context取消后，defer注册的函数为什么不自动执行？
Go里context.Context本身不管理资源生命周期，它只提供信号（Done()通道关闭）和超时控制。很多人误以为调用cancel()会触发defer或自动释放内存——其实不会。defer只在函数返回时执行，和context无关。
- context取消只是关闭
ctx.Done()通道，让监听者能感知“该停了” - 资源（如数据库连接、goroutine、文件句柄）必须显式清理，否则泄漏
- 常见错误：启动goroutine监听
ctx.Done()但没做清理，或把defer close(conn)写在父函数里，而父函数早于context取消就返回了
如何用WithCancel/WithTimeout配合手动资源释放？
最稳妥的方式是把资源生命周期绑定到context取消事件上，而不是依赖defer位置。关键不是“谁来触发”，而是“谁来响应”。
- 启动goroutine监听
<code>ctx.Done()，并在收到信号后调用清理逻辑（如conn.Close()、mu.Unlock()） - 避免在长生命周期函数里用defer关短生命周期资源——比如在HTTP handler里defer关DB连接，但handler可能早于query结束就返回
- 示例：启动一个worker goroutine时，传入
ctx，并在select中监听ctx.Done()和业务channel，退出前执行cleanup()
为什么不能用context.Value存资源句柄再统一回收？
context.WithValue()是只读传递数据的机制，不是资源池。它不提供生命周期钩子，也无法在cancel()时回调。
- 把
*sql.Conn塞进context.WithValue(ctx, key, conn)，cancel后conn还在内存里，且没人知道该不该关 - Value设计初衷是传递请求范围的元数据（如user ID、trace ID），不是对象容器
- 真正需要复用或集中管理的资源，应该用独立的资源池（如
sync.Pool）或显式生命周期控制器，而非context
实际项目中容易被忽略的三个泄漏点
context生命周期和资源生命周期错位，往往出现在边界模糊处。
- HTTP中间件里创建了goroutine但没用
ctx控制其退出——比如日志上报goroutine持续运行，直到进程结束 - 调用第三方库（如
redis.Client的Subscribe）返回的PubSub对象，需手动调用Close()，而它的ReceiveContext()虽支持ctx，但不自动关底层连接 - 测试中用
context.Background()代替context.WithTimeout(t, time.Second)，导致测试卡死或泄漏goroutine
资源回收从来不是context的职责，它是协作契约：谁创建，谁监听Done，谁清理。写清楚“这个conn什么时候关”，比写“用ctx包一层”重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
