Go time.AfterFunc 怎样取消并重置一次性定时器

先记住一个结论：time.AfterFunc 返回的是控制对象 *time.Timer，回调到期后会在独立 goroutine 中执行。还没有触发时，Stop() 返回 true；如果已经触发或已经停止，则返回 false。Stop() 返回 false 时不会替你等待回调结束。

取消定时器和等待回调完成是两件事；重排定时器和保证旧回调不并发，也是两件事。

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

触发信号：你看到的通常不是“定时器泄漏”

一次性延时任务常见于超时提醒、延迟刷新和防抖。排查时先看三个信号：是否保存了返回的 *time.Timer，取消动作是否检查了 Stop 的布尔返回值，以及回调是否可能已经开始。

AfterFunc 的定时器不通过 Timer.C 交付时间值，业务入口就是回调函数。也就是说，不能照搬通道型定时器的“停止后排空通道”写法。下面的结构图只用于说明对象关系，不是运行截图。

AfterFunc、time.Timer、回调 goroutine、Stop 返回值与完成信号的静态关系说明图 — 图1：AfterFunc 定时器生命周期结构说明图，重点查看 Timer 控制边界与回调 goroutine 的分离。

快速判断：Stop 的 true 和 false 分别代表什么

Stop 返回值	应该怎样理解	后续动作
`true`	定时器仍在等待，回调尚未开始	可以认为本次回调被取消
`false`	定时器已经触发，或此前已经停止	回调可能正在运行；另行等待或协作取消

最小取消写法如下。注意：Stop 只是取消尚未开始的触发，不是回调的 join 操作。

package main

import (
    "fmt"
    "time"
)

func main() {
    timer := time.AfterFunc(2*time.Second, func() {
        // 回调由 time.AfterFunc 放到独立 goroutine 中执行。
        fmt.Println("延迟任务开始")
    })

    if timer.Stop() {
        // true 表示回调尚未启动，本次定时触发被取消。
        fmt.Println("定时器已取消")
        return
    }

    // false 只说明已经触发或已经停止，不能据此断言回调已完成。
    fmt.Println("需要另外协调回调完成")
}

处理步骤：用 Reset 重新安排一次性回调

Reset(d) 改变的是下一次回调的等待时间。对 AfterFunc 创建的 Timer，返回 true 表示它仍处于活动等待状态，回调被重新排期；返回 false 表示它已经过期或停止，Reset 会安排回调再次执行。

关键边界在这里：当 Reset 返回 false 时，它不会等待旧回调完成，也不保证随后安排的回调不会和旧回调并发。因此，回调必须能承受重复进入，或者由业务代码提供互斥、完成 channel、上下文取消等协调手段。

time.AfterFunc Reset true、Reset false、旧回调、再次调度与显式同步的静态关系说明图 — 图2：Reset 返回语义与并发边界结构说明图，重点查看 false 分支为何需要额外协调。

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var mu sync.Mutex
    var timer *time.Timer
    var running bool

    run := func() {
        mu.Lock()
        running = true
        mu.Unlock()

        // 真实项目中在这里执行可取消、可重复或幂等的工作。
        fmt.Println("执行一次延迟工作")

        mu.Lock()
        running = false
        mu.Unlock()
    }

    schedule := func(wait time.Duration) {
        mu.Lock()
        defer mu.Unlock()

        if timer == nil {
            // 第一次创建 AfterFunc，回调不通过 Timer.C 返回结果。
            timer = time.AfterFunc(wait, run)
            return
        }

        // true 表示原回调尚未启动；false 时仍需考虑旧回调并发。
        resetOK := timer.Reset(wait)
        fmt.Println("Reset 是否仍在等待：", resetOK, "当前运行：", running)
    }

    schedule(500 * time.Millisecond)
    schedule(2 * time.Second)
}

上例中的 running 只展示观察点，不是通用的并发保护方案。若工作不能重入，应把共享资源的访问放在同一把锁下，或让任务自身使用版本号、幂等键和完成信号；不要只看 Reset 的返回值就认定旧回调已经退出。

回滚路径：取消触发和取消业务工作要同时设计

如果回调内部还会访问数据库、文件或外部请求，建议把“停止后续触发”和“让已经开始的工作尽快退出”分开设计。可以在回调入口读取 context.Context，在实际阻塞操作处继续传递它；必要时再用完成 channel 等待收尾。

type DelayedJob struct {
    timer  *time.Timer
    cancel context.CancelFunc
    done   chan struct{}
}

func (j *DelayedJob) Cancel() {
    // Stop 负责阻止尚未启动的回调，cancel 负责通知已启动的工作。
    if j.timer != nil {
        j.timer.Stop()
    }
    if j.cancel != nil {
        j.cancel()
    }
}

这里省略了构造和并发封装，重点是职责划分：Stop 不承诺等待，cancel 不会自动杀掉 goroutine，done 才能表达“回调确实完成”。生产代码还应保证 Cancel 与调度入口的并发访问受锁保护。