cancel()立即关闭Done()通道并解除父子引用，防止goroutine阻塞和内存泄漏；必须调用且仅需一次，漏调致泄漏，多调无害但无效。
不调用 cancel()，子 Context 的 Done() 通道不会提前关闭，父 Context 也不会清理对它的引用——这直接导致 goroutine 阻塞和内存泄漏，不是“可能”，而是确定会发生。
context.CancelFunc 调用后到底发生了什么
它不是“通知子协程退出”，而是触发两个不可逆的底层动作：
-
Done()通道被立即关闭，所有阻塞在select { case 的 goroutine 会被唤醒 - 父 Context（如
*timerCtx）从内部childrenmap 中移除对该子 Context 的引用，让 GC 可以回收其内存及关联的*time.Timer
这两步缺一不可。只靠超时自动触发 cancel（比如 WithTimeout 到时间后内部调用）并不能替代手动调用——因为业务逻辑可能早于超时完成，此时 timer 和 goroutine 仍持续运行，直到超时那一刻才释放。
为什么 defer cancel() 不总是安全
在 HTTP handler 或中间件中盲目 defer cancel() 容易切断下游调用链：
- 若你在中间件里调用了
ctx, cancel := context.WithTimeout(r.Context(), ...)并defer cancel()，那么后续 handler 拿到的ctx可能已在返回前就被取消 -
r.Context()是由 net/http 自动管理的，它本身已具备客户端断连、超时等取消能力；再套一层WithTimeout后又立即cancel()，等于主动阉割了原生生命周期 - 真正需要
defer cancel()的场景是：你创建了**新派生的、独立于请求生命周期的子 Context**，比如异步发通知、后台落库、定时轮询等
WithTimeout/WithDeadline 的 timer 泄漏怎么排查
泄漏表现通常是 pprof 发现大量 runtime.timer 实例或 goroutine 卡在 timerproc，根源往往是没调用 cancel()：
- 每个
WithTimeout都会启动一个*time.Timer，并 spawn 一个 goroutine 等待触发 - 即使业务函数 return 了，只要没调用
cancel()，timer 就不会Stop()，goroutine 也不会退出 - 高频请求下（如 QPS > 100），几分钟内就能积累数百个空转 timer
- 验证方式：在调用
context.WithTimeout后加一行fmt.Printf("timer addr: %p\n", &timer)（需反射访问），对比 pprof 中 timer 地址是否持续增长
最易被忽略的一点：cancel 函数必须且只能调用一次，但它不 panic —— 漏调会泄漏，多调无害但无用；而真正的危险在于“以为调了，其实没调到”，比如在 error early return 分支里忘了 defer，或者 cancel 被包裹在 if 条件中却始终未进入。
