cancel() 必须调用，因其核心作用是关闭子Context的Done()通道并停止内部timer、解除父子引用；不调用会导致timer持续驻留、goroutine泄漏及内存无法及时回收。
context.WithTimeout 返回的 cancel() 为什么必须调用
不调用 cancel() 会导致底层 timer 持续驻留 runtime，即使超时已触发。Go 的 context.WithTimeout 内部使用 time.NewTimer，而该 timer 不会自动销毁——它必须被显式 Stop()，否则会成为 goroutine 和 timer heap 中的残留项。
常见错误是认为“超时一到，timer 就自动回收”，实际并非如此。未调用 cancel() 时，timer 仍处于 active 状态，直到其 channel 被读取（即 发生），但若业务逻辑提前退出、没走到 select 分支，这个读取就永远不会发生，timer 就一直挂着。
- 每次
context.WithTimeout都会新建一个*timer，并注册进 Go runtime 的 timer heap -
cancel()内部执行timer.Stop()+ 关闭Done()通道 + 清理父 context 的子节点引用 - 漏掉
cancel()会导致 timer heap 泄漏，长期运行服务中可观测到GODEBUG=gctrace=1下 timer 数量持续增长
cancel() 调用时机对资源释放的影响
必须在 context 生命周期结束时调用 cancel()，且优先于所有依赖该 context 的资源关闭操作。典型反例是把 cancel() 放在 defer resp.Body.Close() 后面——若 HTTP 请求提前完成，resp.Body.Close() 可能阻塞（如服务端未发 FIN），导致 cancel() 永远不执行。
正确做法是让 cancel() 成为最外层的 defer，或与资源获取成对出现：
- HTTP 客户端：先
req = req.WithContext(ctx)，再defer cancel()，最后client.Do(req) - 数据库查询：在
db.QueryContext(ctx, ...)前完成defer cancel() - 自定义协程：在
go worker(ctx)之前调用defer cancel()，确保无论 worker 是否启动，cancel 都可执行
和 time.Timer 混用时的冲突点
不能在同一个 select 中同时监听 和 <code>，这会造成重复唤醒、逻辑错乱，且掩盖了 <code>cancel() 的真实作用。
context.WithTimeout 已经封装了 timer 的全部生命周期管理，额外引入 time.After 属于冗余且危险的操作：
-
time.After返回的是不可取消的chan Time，无法响应外部中断 - 若
ctx.Done()先触发，time.After的 channel 仍保持 open，后续可能意外触发（尤其在循环中） - Go runtime 对 timer 的调度基于统一 heap，混用多个 timer 实例会增加调度开销，且无法保证 cancel 信号穿透
真正需要的是监听 ctx.Done() 并检查 ctx.Err() 类型：errors.Is(ctx.Err(), context.DeadlineExceeded) 才代表超时，而非手动比对时间戳。
超时后 timer 是否立即从 runtime 移除
不是立即。调用 cancel() 后，timer 会被标记为 stopped，但其内存块不会马上回收——需等待下一轮 GC 扫描 timer heap 时清理。不过只要 cancel() 被调用，该 timer 就不再参与调度，也不会触发回调。
关键点在于：timer 的“存在”和“活跃”是两回事。泄漏风险只来自未调用 cancel() 导致的持续活跃；哪怕 timer 对象还在内存里，只要它已 stop，就不会影响性能或产生 goroutine 阻塞。
所以不必纠结“timer 对象是否被 GC”，而要确保每一对 WithTimeout/WithDeadline 都有对应的 cancel() 调用——这是唯一可控、可验证的防线。
