调用 cancel() 函数是唯一能主动触发上下文取消的方式，它直接关闭 ctx.Done() 通道，使监听该通道的协程立即收到信号，前提是协程确实在监听且未阻塞于其他操作。
调用 cancel() 函数是唯一能主动触发上下文取消的方式，它会立即关闭 ctx.Done() 通道，所有正在 select 监听该通道的协程都会立刻收到信号——但前提是它们真的在监听，且没卡在其他阻塞操作上。
cancel() 调用后发生了什么
它不是“发消息”或“通知”，而是直接关闭一个内部 channel（ctx.Done() 返回的那个）。Go 运行时会唤醒所有因 而阻塞的 goroutine，让它们从 <code>select 中退出。没有监听、没进 select、或正在 time.Sleep / ch <- / <-ch 等非 context-aware 操作上的协程，完全感知不到这个动作。
-
cancel()只能安全调用一次；重复调用不 panic，但属于逻辑错误，建议用sync.Once封装 - 调用后
ctx.Err()立即返回context.Canceled，不再为nil - 所有派生自该 ctx 的子 ctx（包括用
context.WithValue、context.WithTimeout创建的）也会同步关闭自己的Done()通道 - 资源不会自动释放——你得在
select分支里手动关文件、断连接、清理状态
为什么子协程收不到取消信号
根本原因不是 WithCancel 失效，而是子协程压根没正确接入 context 协作机制。常见漏点：
- 启动 goroutine 时没把
ctx当参数传进去，而是闭包捕获外部变量（生命周期错乱，可能已失效） - 循环体里写
if ctx.Err() != nil { break }，这只能检测“已经取消”，无法响应“即将取消”——必须用select等待 - 阻塞操作没包裹在
select里：比如直接time.Sleep(10 * time.Second)，期间完全不看 context；应改用timer.C和ctx.Done()并列等待 - 调用了不支持 context 的老库函数（如旧版
database/sql驱动），或封装 http client 时忘了用req.WithContext(ctx)
如何确保深层嵌套协程都响应取消
没有魔法穿透，只有逐层显式传递 + 逐层 select 响应。关键动作必须出现在每一层：
立即学习“go语言免费学习笔记（深入）”；
- 每个 goroutine 启动函数签名第一项必须是
ctx context.Context，禁止省略或挪到后面 - 所有可能耗时的操作（
http.Do、db.Query、time.Sleep、ch <-、<-ch）都要放进select，与并列 - 如果某层要再启新 goroutine，必须把当前
ctx显式传下去，不能依赖“父 ctx 还活着”这种假设 - 检查第三方库文档，确认其方法是否接受
context.Context参数；不支持的，得自己加超时或用select包裹
cancel() 该在哪儿调用、何时调用
它本质是个“终止开关”，调用时机由业务逻辑决定，但调用位置有硬约束：
- 必须由创建它的那一层调用（即
ctx, cancel := context.WithCancel(...)所在作用域）；子协程绝不能持有或调用cancel - 父协程若需等待子协程退出，应在
defer cancel()前先waitGroup.Wait()或用select等待子完成，否则cancel()可能过早触发 - HTTP handler 中通常配合
defer cancel()，但要注意：如果 handler 已 return，cancel()仍要执行，否则子协程可能泄漏 - 不要在子协程里判断
ctx.Err() == context.Canceled后再调cancel()——这是反模式，取消权只属于发起者
最易被忽略的点是：取消信号本身只是关闭一个 channel，它不终止任何 goroutine，也不释放任何资源。真正让程序停下来、清理掉的，是你写在 case 分支里的那几行代码——那里才是取消逻辑的实际落点。
