Go time.AfterFunc Reset 失败时如何判断旧回调状态

排查 time.AfterFunc 时，最容易误读的是 Timer.Reset 的布尔返回值。结论先说清：对函数型定时器，Reset(false) 只说明原定时器已经到期或被停止，随后会再安排一次回调；它不代表旧回调已经执行完，也不保证新旧回调不会并发。要判断旧回调状态，必须在回调内部主动记录“已开始”和“已完成”。

Reset(false) 到底说明了什么

AfterFunc 会在自己的 goroutine 中调用函数，返回的 Timer.C 是 nil。因此它和 NewTimer 的通道型定时器不是同一种判断模型。

先让旧回调发出 started，再判断 finished

如果业务确实需要判断某一次旧执行是否结束，先给这次执行建立明确的事件边界。下面的示例让旧回调先发出 started，调用方确认它已经进入后再 Reset；当返回 false 时，等待同一次执行发出的 finished。第二次回调被安排在更晚时间，因此不会抢走这一次完成信号。

package main

import (
	"fmt"
	"time"
)

func main() {
	started := make(chan struct{}, 2)
	finished := make(chan struct{}, 2)

	timer := time.AfterFunc(20*time.Millisecond, func() {
		started 

这里的关键是“完成”由回调自己定义，而不是由 Reset 猜测。若回调还会修改共享 map、连接或缓存，应在发出 finished 前完成解锁、提交或状态切换。

并发窗口里不要只看一个 bool

上面的例子适合说明一次明确的旧执行。真实服务可能连续 Reset，或允许多个回调进入。此时建议给每次执行分配 run ID，把 started、finished 和业务结果绑定到同一个 ID；共享数据则用 sync.Mutex、串行 worker 或原子变量保护。

type Result struct {
	RunID  uint64
	Err    error
	Done   chan struct{}
}

// 回调结束时关闭自己的 Done，调用方等待的是具体 run，而不是 Reset 返回值。
func finish(r *Result, err error) {
	r.Err = err // 若有多个读写方，实际项目应在锁内更新结果。
	close(r.Done)
}

还要注意：如果在旧回调尚未开始时就拿到 Reset(false)，调用方并没有一个天然的“旧函数完成事件”可以读取。此时应调整协调器，让每次调度先登记 run ID 和完成通道，再由回调回填状态；不要用固定 Sleep 猜测它何时结束。

什么时候应该换成 NewTimer 或 Stop

如果需求是“等待一个可接收的时间事件”，使用 NewTimer 更直观；如果需求是“执行一次函数并在不需要时取消”，使用 AfterFunc 后调用 Stop。但无论是 Stop(false) 还是 Reset(false)，都只描述定时器层面的状态。要知道函数是否完成，仍需回调内部的同步协议。

相关问题

Reset(false) 会不会让回调执行两次？

有可能。它会为函数再安排一次执行，而旧函数可能已经开始或仍未返回；如果两次执行不能重叠，必须增加串行锁或协调器。

AfterFunc 的 Timer.C 能用来等回调吗？

不能。函数型定时器返回的 C 不用于回调通知，应使用完成 channel、sync.WaitGroup 或其他明确的同步协议。

Stop(false) 和 Reset(false) 都表示执行结束吗？

都不是。它们只能说明定时器已经不在可直接停止或重新排期的等待状态，不能替代函数自身的完成信号。