context.withcancel 是唯一靠谱的起点，因它显式创建带取消通道的上下文，使 ctx.done() 可被 select 监听并响应取消；用 context.background() 或 context.todo() 则无取消能力。
context.WithCancel 为什么是唯一靠谱的起点
子协程停不下来，根本原因往往是没在启动时就拿到可取消的 context.Context。用 context.Background() 或 context.TODO() 启动协程，等于默认放弃了取消能力——它们没有取消通道，ctx.Done() 永远不会关闭。
必须用 context.WithCancel 显式创建带取消能力的上下文，再把返回的 cancel 函数保存好，后续才能主动触发停止：
parentCtx, cancel := context.WithCancel(context.Background()) go worker(parentCtx) // 子协程只接收 ctx，不持有 cancel // …… 触发停止时调用： cancel() // 这会关闭 parentCtx.Done()
-
cancel()只能调用一次；重复调用无副作用但属逻辑错误，建议配合sync.Once封装 - 不要把
cancel函数传给子协程——子协程只应监听ctx.Done()，不该有取消权 - 如果父协程自己也要响应取消（比如等待子协程退出），记得用
defer cancel()防止泄漏
子协程里怎么正确监听 Done() 并退出
监听 ctx.Done() 不是“检查一下就算了”，它本质是个阻塞 channel，必须用 select 等待，否则会漏掉信号或忙等消耗 CPU。
常见错误是写成 if ctx.Err() != nil 放在循环开头——这只能检测已发生的错误，无法响应未来取消。
func worker(ctx context.Context) {
for {
select {
case
-
select中case 是唯一可靠入口；<code>default分支用于非阻塞工作，但别让它跑太快，加time.Sleep或用更合理的任务粒度 - 如果工作本身是阻塞调用（如
http.Get、time.Sleep、ch ），必须把 ctx 传进去，让底层支持取消（例如用 <code>http.NewRequestWithContext） - 别在
Done()触发后还继续发消息到已关闭的 channel，容易 panic
多层子协程怎么保证全部收到取消信号
靠“传递 ctx”就行，不需要手动广播。只要每个子协程都从上一级拿到同一个 ctx（或它的派生），cancel() 一调，所有监听者都会同时收到。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
重点在于：每开一个新协程，都要用当前 ctx 派生新 ctx，而不是复用原始 ctx 或漏传。
// 正确：逐层传递 + 派生
go worker1(ctx) // ctx 来自 WithCancel
go worker2(context.WithValue(ctx, key, val)) // 派生新 ctx，仍共享 Done()
go func() {
subCtx, _ := context.WithTimeout(ctx, 5*time.Second)
go worker3(subCtx) // 超时也自动取消，且和父级同步
}()
- 避免在 goroutine 内部重新调用
context.WithCancel—— 这会切断与父级的取消链 - 如果某子协程需要独立超时控制（比如 IO 限时），用
context.WithTimeout或WithDeadline派生，它们的 Done() 会在超时或父级取消任一发生时关闭 - 别用
context.WithValue传取消相关逻辑，它只是携带数据，不影响取消行为
cancel() 调用后子协程还在跑？检查这三件事
最常踩的坑不是 context 用错了，而是协程自己没配合好——取消信号到了，但代码没响应。
典型现象：cancel() 已调，ctx.Err() 返回 context.Canceled，但 goroutine 仍在打印日志或往 channel 写数据。
- 检查是否遗漏
select，尤其在 for 循环里写了if ctx.Err() != nil { break }却没return - 检查是否在
select外还有长耗时操作（比如大数组遍历、未设 timeout 的网络请求），这些地方要主动插if ctx.Err() != nil { return } - 检查是否对已关闭的 channel 执行了发送操作（
ch ），panic 会让协程提前退出，反而掩盖了取消逻辑问题
context 不是魔法，它只负责通知；真正停下来，靠的是每一层代码对 的诚实响应。越深的调用栈，越容易藏住没检查 ctx 的角落。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
