Go语言长时运行函数的Context取消实现疑问

你的假设完全正确。

核心结论 #

《Learning Go》里的longRunningThingManager模式仅能解除调用者的阻塞状态，但如果longRunningThing自身不主动检查context的取消信号，对应的goroutine会一直运行到结束，确实会造成资源浪费，甚至引发不必要的副作用（比如持续打印输出、占用系统资源）。

为什么长时运行函数必须自己检查context？ #

Go的context取消是协作式的：Go runtime不会强制终止任何goroutine，必须由函数主动监听ctx.Done()通道的信号，自行终止执行。你修改后的longRunningThing版本才是正确的实现方式：

func longRunningThing(ctx context.Context, data string) {
    for i := 0; i < 100; i++ {
        select {
        case <-ctx.Done():
            return // 主动响应取消，终止goroutine
        default:
            fmt.Printf("%v %v\n", data, i)
            time.Sleep(1 * time.Second)
        }
    }
}

这里还有个优化点：原代码里的time.Sleep会让goroutine阻塞1秒，即使context在这期间被取消，也得等sleep结束才能响应。可以改成结合time.After的方式，让取消信号能立即被处理：

func longRunningThing(ctx context.Context, data string) {
    for i := 0; i < 100; i++ {
        select {
        case <-ctx.Done():
            return
        case <-time.After(1 * time.Second): // 用通道替代sleep，响应更及时
            fmt.Printf("%v %v\n", data, i)
        }
    }
}

《Learning Go》中模式的适用场景 #

书中的longRunningThingManager模式不是用来终止goroutine的，它的作用是：

• 让调用者不必一直阻塞等待longRunningThing完成，能在context取消时立即返回结果
• 这个模式的前提是：longRunningThing本身已经实现了context取消的检查（也就是你修改后的版本），或者该函数的执行成本极低、没有副作用，即使跑完也不会有问题

如果脱离这个前提直接使用，就会导致goroutine泄露，浪费系统资源。

总结 #

• 长时运行的函数必须主动在内部定期检查context的取消信号，这是实现goroutine优雅终止的核心
• 包装器模式是对调用体验的优化，不能替代函数内部的取消逻辑

内容的提问来源于stack exchange，提问作者Max