cancel()未生效的根本原因是某层漏掉select监听或误用阻塞操作，而非context无法传递；取消依赖显式检查ctx.done()，每层必须传入并使用ctx，否则下游彻底失控。
深层嵌套协程中 cancel() 为什么没生效
根本原因不是 context 不能传下去，而是某一层漏掉了 select 监听或误用了阻塞操作。取消信号本身只是关闭一个 chan struct{}，goroutine 是否响应、何时响应，完全取决于你有没有在它执行路径上显式检查 ctx.Done()。
- 常见错误：在子函数里写
time.Sleep(2 * time.Second)而不是用select等待，这段睡眠期间完全不响应取消 - 闭包捕获外部
ctx变量（如go func() { doWork(ctx) }()），导致协程启动时实际拿到的是旧值或未传递的 context - 某层调用新建了
context.Background()或context.TODO()，切断了取消链路 - 第三方库回调中自行构造新 context（比如某些 metrics reporter 的 hook），绕过了上游传播
每一层都必须显式接收并传递 ctx 参数
context 不会“自动继承”或“向上查找”，它只沿你显式传入的参数链向下流动。哪怕只有一层忘了把 ctx 当参数传进去，下游所有 goroutine 就彻底脱离控制。
- 正确写法：
func handleRequest(ctx context.Context) { go worker(ctx) }→func worker(ctx context.Context) { go subWorker(ctx) } - 错误写法：
func worker() { go subWorker() }，即使subWorker内部有select，它拿到的也是context.Background() - HTTP handler 中常见断裂点：中间件里调用了
log.Printf(...)，而日志库内部又启了 goroutine 且没透传ctx
超时起点不是请求开始，而是 WithTimeout 执行时刻
如果你在 handler 入口就调 context.WithTimeout(ctx, 5*time.Second)，那这 5 秒包含 DNS 解析、锁竞争、GC STW 等所有前置耗时——真正发 HTTP 请求时可能只剩 100ms 了。
- 想让“网络请求发出”才开始计时？就在
http.Client.Do前一刻才调context.WithTimeout - 嵌套多个
WithTimeout：外层超时包含内层构造开销，总耗时不等于各层之和；建议只在外层设主超时，内层用context.WithValue或直接复用 -
context.WithDeadline很少需要，机器时间被回拨会导致提前取消；绝大多数场景用context.WithTimeout更安全
cancel() 必须覆盖所有退出路径，不止 defer
defer cancel() 是基础兜底，但函数有多个 return、panic 后 recover、或提前返回时，它根本不会执行。漏一次，就多一个泄漏的 timer 和 goroutine。
- 每个
return前手动加cancel()，或统一收口到一个cleanup()函数里调用 - panic 场景：recover 块里必须补调
cancel()，否则 timer 继续跑完剩余时间 - HTTP handler 中即使已收到
ctx.Err() == context.DeadlineExceeded，仍要调cancel()，否则子 context 不会递归清理 - timerCtx 泄漏最隐蔽：业务提前完成却没调
cancel()，*time.Timer仍在后台跑，直到超时才触发自身 cancel
深层嵌套的可靠性不取决于层数上限，而取决于每一条调用路径是否严格遵循“传 ctx → select 监听 → 每个出口 cancel”。最容易被忽略的，是那些看似无关的辅助 goroutine —— 它们只要没接 ctx，就永远游离在取消体系之外。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
