Go context.CancelFunc 传给多个收尾函数如何避免重复收尾

在带超时、错误退出和人工停止的 Go 长任务里，多个函数共享同一个 context.CancelFunc 是正常做法。需要特别区分两件事：重复调用 cancel() 只是重复发出停止信号，标准库会让它安全返回；而连接、文件、事务等资源的关闭动作并不会因为使用了 context 就自动幂等。稳妥的设计是让所有入口只请求停止，由一个协调点等待工作退出，再统一清理资源，并用 sync.Once 做最后保护。

CancelFunc 可以共享，但清理责任不能含糊

context.WithCancel 返回子 context 和一个取消函数。调用取消函数后，子 context 的 Done() 会关闭，监听它的工作协程可以结束。多个 goroutine 同时调用同一个 CancelFunc，结果仍然是同一个“已取消”状态，不需要为了保护 cancel() 再包一层锁。

真正容易出错的是把清理写进多个监听者：worker A 收到取消后关闭连接，worker B 也关闭连接，主流程的 defer 再关闭一次。某些类型第二次关闭会返回错误，某些自定义资源甚至会触发竞态。因此应把“请求停机”和“释放资源”拆成两个动作。

用统一停止入口收敛超时、错误和人工操作

最小结构是让所有触发源只调用 requestStop，而不直接操作连接、文件或事务。这样无论哪个入口先到，工作协程看到的都是同一个 context 状态：

package main

import (
    "context"
    "sync"
)

func run(parent context.Context, closeResources func()) {
    ctx, cancel := context.WithCancel(parent)
    defer cancel() // 函数返回时释放 context 关联的资源

    var cleanupOnce sync.Once
    cleanup := func() {
        cleanupOnce.Do(func() {
            closeResources() // 只有协调点真正释放共享资源
        })
    }
    requestStop := func() {
        cancel() // 超时、错误和人工停止都可以安全重复调用
    }

    _ = ctx
    _ = requestStop
    _ = cleanup
}

示例把取消函数隐藏在一个窄入口里，便于后续统一记录停止原因。生产代码中，超时分支、某个 worker 的错误分支和管理接口都调用 requestStop；它们不应该各自执行 closeResources。

等待工作退出后再做一次资源清理

如果资源仍被 worker 使用，收到取消信号后立即关闭它，可能把“让协程退出”变成新的读写错误。更清晰的顺序是：发出取消、等待 worker 返回、执行清理。多个退出路径都可能进入最终收尾时，让清理函数具备幂等性：

var cleanupOnce sync.Once

cleanup := func() {
    cleanupOnce.Do(func() {
        // 这里按依赖顺序关闭连接、文件等共享资源
        closeResources()
    })
}

requestStop() // 任意入口可调用，不在这里直接关闭资源
workers.Wait()
cleanup() // 主协调点执行；其他兜底路径再次调用也只会生效一次

sync.Once 只保证函数体执行一次，不会自动修复清理顺序，也不会替你处理 closeResources 返回的错误。若清理必须报告错误，应在 Once 内保存第一次错误，再由协调者统一返回。

四个边界要在代码评审时确认

第一，parent 不能为 nil；没有上级取消需求时使用 context.Background()。第二，defer cancel() 仍要保留，它负责正常返回路径上的释放，即使其他入口已经调用过也没问题。第三，监听 ctx.Done() 的 worker 要真正从阻塞 I/O 或 channel 操作中退出，否则等待会一直卡住。第四，若要区分“超时、主动停止、业务错误”，应单独保存原因，不要只依赖 ctx.Err()。

可以把设计检查压缩成一句话：CancelFunc 负责广播停止，worker 负责响应停止，协调者负责等待和清理，sync.Once 负责防止清理入口失守。

常见问题

CancelFunc 要不要用 mutex 保护？

通常不需要。标准 context 的取消函数可以被多个 goroutine 同时调用；锁更应该用在你自己的共享状态或资源清理逻辑上。

只写 defer cancel() 能防止重复关闭连接吗？

不能。它只负责取消 context；连接、文件等资源仍应由明确的清理 owner 关闭，必要时配合 sync.Once。

为什么不让每个 worker 收到 Done 后自己清理？

如果资源是共享的，多个 worker 会争夺同一清理责任。让 worker 退出、让协调者清理，职责更容易验证。

结论是：可以放心把一个 CancelFunc 传给多个收尾函数，但这些函数最好只做“请求停止”。真正的资源释放要集中、可等待、可记录错误，并用一次性门闩保护重复入口。