Go goroutine 为什么 defer 不能替代显式取消

Go 里经常能看到 defer cancel()，但它不能替代 goroutine 内部的显式取消逻辑。defer 只保证“所属函数返回时执行清理动作”；它不会强制停止另一个仍在运行的 goroutine。真正的取消闭环是：调用方发出信号，worker 主动监听信号并退出，调用方再等待退出完成。

把 defer cancel() 当作资源回收保险，把 ctx.Done() 或专用停止通道当作 worker 的退出协议，两者职责不同。

官方资料：https://pkg.go.dev/context

defer 只负责当前函数的收尾

defer 绑定的是当前函数的返回路径。下面的清理动作会在 serve 返回时执行，但不会让已经启动的 goroutine 自动结束：

func serve() {
    // defer 只负责 serve 自己持有的资源。
    defer closeResource()

    go func() {
        // 没有停止条件时，这个 goroutine 仍可能继续运行。
        for {
            doOneJob()
        }
    }()

    return
}

即使 serve 很快返回，匿名函数仍有自己的执行栈和调度生命周期。此时 defer closeResource() 只关闭当前函数拥有的资源，不会替 worker 补上一条“请退出”的消息。

显式取消需要一个可观察的协议

最小的做法是让调用方创建 context.WithCancel，把 Context 传给 worker，并在 worker 的循环里用 select 监听 Done。defer cancel() 仍然可以保留，但它负责函数提前返回时的兜底释放；真正让 worker 结束的是显式调用 cancel() 后的信号传递。

func runWorker() {
    // cancel 既用于主动停止，也用于函数返回时释放派生 Context 的资源。
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        // 无论正常停止还是提前返回，都要通知等待方。
        defer wg.Done()
        for {
            select {
            case 

这里有两个时间点：cancel() 让 ctx.Done() 变为可读，wg.Wait() 则等待 worker 执行完退出前的清理。只调用前者而不等待，调用方不能把“已发出取消”误写成“已经退出”。

周期任务不能只在循环末尾检查

如果 worker 用 time.Sleep 直接等待，取消信号到了也只能等睡眠结束后才被处理。把等待器放进 select，可以让取消和下一次工作竞争同一个等待点：

func poll(ctx context.Context) {
    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop() // 释放 ticker，避免周期任务留下计时器。

    for {
        select {
        case 

如果 fetchOnce 调用了支持 Context 的 API，还应继续把 ctx 传进去。否则外层 select 已经退出，内部网络或数据库调用仍可能阻塞，取消就只停掉了外层循环。

为什么 defer cancel 不是“自动终止按钮”

下面的写法并非错误，但它表达的是“run 返回时再取消子 Context”，不是“现在就停止 worker”：

func run(ctx context.Context) error {
    // 只有 run 返回时才会执行 cancel。
    child, cancel := context.WithCancel(ctx)
    defer cancel()

    return doWork(child)
}

它适合保证派生 Context 不会因为遗漏释放而长期存在；如果业务在中途发现结果已经无效，仍应在那个分支直接调用 cancel()，并让下游 API 和 goroutine 监听 child.Done()。不要依赖函数返回的时机来模拟实时停止。

排查 goroutine 停不下来的四个检查点

1. worker 是否监听信号：只启动 goroutine、没有 ctx.Done() 或停止通道的循环，本身没有退出协议。
2. 监听是否覆盖阻塞点：把检查写在长时间阻塞调用之后，取消响应仍会变慢；优先使用支持 Context 的 API。
3. 取消后是否等待：调用 cancel() 后配合 WaitGroup、结果通道或其他明确的完成通知。
4. 清理是否属于 worker：worker 自己持有的 ticker、文件或连接，应在它自己的返回路径中用 defer 清理。

结语

判断 goroutine 是否能被停止，不要只看有没有 defer。先找停止信号从哪里发出，再看 worker 在哪些等待点读取它，最后确认调用方是否等待退出完成。这样写出来的 defer cancel() 是可靠的清理兜底，而不是把生命周期管理交给函数返回时刻。

取消 Context 后 goroutine 一定马上退出吗？

不一定。Context 是协作式信号，worker 必须监听它；如果正在执行不可取消或很慢的操作，退出会等该操作返回。

为什么已经调用 cancel 还要 Wait？

cancel 只改变取消信号状态，Wait 才让调用方等到 worker 执行完清理并返回。

worker 自己应该使用 defer 吗？

应该。worker 可以用 defer 关闭自己持有的资源、调用 wg.Done，但这不等于它拥有了外部取消能力。