Go 计时器AfterFunc 回调和 Stop 同时发生怎么办

使用 time.AfterFunc 时，回调和 Timer.Stop() 在临界点同时出现并不表示 Go 失控。关键是：Stop() 只负责阻止尚未启动的回调；如果它返回 false，回调可能已经在自己的 goroutine 中启动，但 Stop() 不会等待回调结束。

官方文档：https://pkg.go.dev/time

先分清 Stop 返回值代表什么

函数型计时器和通道型计时器的处理方式不同。AfterFunc 到期后直接调用函数，返回的 Timer.C 为 nil；因此不要照搬 NewTimer 的“停止后排空通道”写法。对 AfterFunc 来说，Stop 的布尔值是一次取消尝试的结果，不是回调生命周期状态。

旧写法的风险在于把取消当成完成

下面的写法只能判断是否成功阻止了回调，不能安全地释放回调仍在使用的共享资源：

timer := time.AfterFunc(200*time.Millisecond, func() {
    // 回调在独立 goroutine 中执行，可能仍会访问 result
    result = loadResult()
})

if timer.Stop() {
    // 中文说明：只代表回调尚未启动，不代表所有资源都已完成清理
    closeResource()
}

如果 Stop 返回 false，调用方仍然可能和回调同时访问 result 或底层资源。即使返回 true，也应确认是否存在其他路径会触发相同的清理逻辑。真正要解决的是共享状态的所有权，而不是把一次布尔返回值扩大解释。

需要等待回调结束时显式协调

让回调在退出前发送完成信号，调用方再决定何时清理。下面示例用一次性关闭的 done 通道传递“回调已经离开”的事实；共享结果用互斥锁保护，避免取消路径和回调路径发生数据竞争。

var mu sync.Mutex
var result string
done := make(chan struct{})

timer := time.AfterFunc(200*time.Millisecond, func() {
    defer close(done) // 中文说明：无论正常返回还是提前结束，都通知调用方
    value := loadResult()
    mu.Lock()
    result = value // 中文说明：和读取方共用同一把锁保护共享结果
    mu.Unlock()
})

if !timer.Stop() {
    

这段结构的前提是：当 Stop 返回 true 时，回调不会再启动，因此可以走取消分支；当返回 false 时，等待 done 才能把“已经启动”和“已经结束”区分开。若回调可能因其他原因提前退出，defer close(done) 尤其重要。

迁移和回归检查清单

1. 把所有 AfterFunc 的 Stop 调用找出来，标记其返回值是否被忽略。
2. 检查回调是否访问共享变量、连接、文件或取消后的业务对象。
3. 对需要收尾的回调增加 done 或 sync.WaitGroup，并保证每条回调退出路径都报告完成。
4. 让取消、超时、正常完成三条路径分别负责一次清理；必要时用锁或原子状态实现幂等。
5. 用竞态检测覆盖“接近到期时调用 Stop”和“回调已开始时释放资源”两种边界。

若业务只需要尽量取消一次尚未执行的任务，直接检查 Stop 返回值即可；若业务要求等待任务结束、回收资源或读取回调结果，就必须另建完成协议。不要把 false 当成失败重试信号，也不要把它当成回调已经执行完毕。

常见疑问

AfterFunc 的 Timer.C 可以用来等待回调吗？

不可以。AfterFunc 返回的计时器不使用 C 通知回调，应该在回调中通过 done、WaitGroup 或业务结果通道表达完成。

Stop 返回 false 后要不要再次调用 Stop？

通常没有意义。它已经说明计时器到期或停止；下一步应根据业务协议等待回调完成、确认状态，或执行幂等清理，而不是靠重复调用改变回调生命周期。