Context不是自动管理生命周期的魔法，而是需手动编织的取消信号网；http.Request.Context()不可直接传给后台goroutine，因其生命周期由客户端连接控制，应派生新context或用context.Background()；WithTimeout计时从调用时刻开始；goroutine必须显式监听ctx.Done()否则Context无效。
Context 不是“自动管理生命周期”的魔法，而是你必须亲手编织的取消信号网——漏掉任意一个监听点，goroutine 就会卡死、泄漏、超时失效。
为什么 http.Request.Context() 不能直接传给后台 goroutine
HTTP handler 里的 r.Context() 生命周期由客户端连接控制：用户关页面、网络中断、响应写完，它就立刻被 cancel。但后台任务（比如发 MQ、写审计日志、轮询状态）往往需要独立存活，甚至比请求更久。
常见错误现象：go sendNotification(r.Context(), msg) 导致通知只发一半就被中断；或 go startPolling(r.Context()) 在请求结束时意外退出，状态同步断层。
- 正确做法是派生新 context：
ctx, cancel := context.WithTimeout(r.Context(), 10*time.Second)，再传给 goroutine，并在业务完成时调用cancel() - 若任务完全脱离请求（如异步落库、推送），应改用
context.Background()起始，再配WithTimeout或WithCancel自主控制 - 永远别把
r.Context()当通用 cancel 源塞进异步逻辑里——它的取消时机你无法掌控
context.WithTimeout 的计时起点在哪
超时倒计时从 context.WithTimeout() 这行代码执行完毕那一刻开始，不是从 goroutine 启动、也不是从 HTTP 入口、更不是从 DB 连接建立时算起。
立即学习“go语言免费学习笔记（深入）”；
这意味着：如果你在 WithTimeout 后还做了耗时初始化（如加载配置、解密 token、建连接池），真正留给核心逻辑的时间会明显缩水。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 实操建议：把
WithTimeout尽量靠近实际阻塞操作前，比如在调用http.Do()或db.QueryRow()前才创建 - 避免在 for 循环里反复调用
WithTimeout—— 每次都新建 timer，GC 压力陡增 - 整条链路需统一耗时限制？入口处设一次
WithTimeout，子调用复用同一ctx，而非各自设超时
goroutine 不监听 ctx.Done() 就等于没用 Context
Context 从不强制杀死 goroutine，它只发信号。你看到 ctx.Err() == context.Canceled，不代表那个 goroutine 已退出——它可能还在 for 里空转、还在读 channel、还在等锁。
典型泄漏场景：启动一个轮询 goroutine，但忘记在 select 中监听 ctx.Done()，服务重启时它还在后台刷日志，内存和连接持续增长。
- 所有阻塞操作前后都应检查：
time.Sleep、ch 、<code>、<code>db.Query、http.Do - 不要只靠
if ctx.Err() != nil判断——这无法捕获正在阻塞中的 goroutine；必须用select { case - 每个后台 goroutine 启动时，都要确保有且仅有一个
select或循环条件显式消费ctx.Done()
context.WithCancel 该用在哪儿、不该用在哪儿
context.WithCancel 的唯一目的，是主动终止一组关联 goroutine。它不是通用参数传递工具，也不是“看起来规范”的装饰品。
常见误用：func handle(req *http.Request) { ctx, cancel := context.WithCancel(req.Context()); defer cancel(); ... } —— 忘记调用 cancel()，导致 goroutine 泄漏；或在纯计算函数（JSON 序列化、配置解析）里硬塞 context，徒增开销。
- 该用：长轮询、流式响应、后台任务超时控制（配合
time.AfterFunc） - 不该用：短平快纯内存操作（如
json.Marshal）、每个 handler 盲目封装、无阻塞逻辑 - 关键提醒：每次调用
context.WithCancel都生成一个必须手动调用的cancel()函数——漏调 = goroutine 永远卡在select
最常被忽略的点：Context 的取消信号是单向广播，不保证 goroutine 立即退出。你得自己确保清理动作（关 channel、释放锁、调用 http.Client.CloseIdleConnections()）跟在 case 后面，否则资源照样泄漏。
