Go timer.Stop 返回 false 时如何判断回调已开始

调用 time.AfterFunc 创建定时回调时，timer.Stop() 返回 false，可以判断定时器已经到期，回调函数也已经在独立的 goroutine 中启动；但这个返回值不能证明回调已经执行完。若业务只关心“回调有没有进入”，这个 false 就是标准库给出的判断；若还要观察回调入口或等待它收尾，应在回调内部主动发出信号。

Stop 返回 false，判断到的是哪一层状态

time.Timer 有两种容易混淆的创建方式。time.AfterFunc(d, f) 到期后会在自己的 goroutine 中调用 f，返回的 Timer 只用来取消这次调用，Timer.C 也不会提供通知。此时如果 Stop() 返回 false，标准库的语义是：定时器已经到期，f 已经开始；Stop 不会等它执行结束。

这和 time.NewTimer(d) 不一样。后者到期时向 t.C 发送时间值，Stop() == false 只表示它已经到期或此前已经停止，不能据此推导“某个回调已经开始”。先确认创建方式，再解释返回值，是排查定时任务重复执行、取消失效时最重要的一步。

给回调入口增加 started 信号

如果日志、测试或上层协调需要精确观察“回调已经进入函数体”，最直接的办法是在回调第一处关闭一个只读信号。调用方看到 Stop 返回 false 后等待该信号，就不会把“定时器到期”误写成“业务代码已经走完”。

package main

import (
	"fmt"
	"time"
)

func main() {
	started := make(chan struct{})
	done := make(chan struct{})

	timer := time.AfterFunc(80*time.Millisecond, func() {
		close(started) // 回调进入函数体时只关闭一次入口信号
		defer close(done) // 无论正常返回还是栈展开，都标记回调结束
		fmt.Println("业务回调开始执行")
		time.Sleep(20 * time.Millisecond) // 用短暂工作模拟实际业务
	})

	if timer.Stop() {
		fmt.Println("回调尚未启动，定时器已取消") // true 表示这次停止抢在到期前
		return
	}

	

这段代码里，Stop 的判断必须先于等待信号：返回 true 时回调不会启动，等待 started 反而会永久阻塞；返回 false 时，标准库保证这个 AfterFunc 回调已经启动，随后等待入口信号是安全的。

把“已开始”和“已完成”分开处理

工程代码经常把 Stop() == false 当作“回调已经处理完，所以可以释放资源”，这会留下竞态。回调可能刚进入函数体，也可能正在访问共享状态；调用方若要复用对象、关闭连接或发送下一轮任务，应该等 done，而不是只看 Stop。

done 的关闭放在 defer 中，是为了避免某个提前返回路径漏发完成通知。若回调可能被改造成多次调度，建议为每次执行建立独立状态；不要重复关闭同一个 channel。

几个容易写错的边界

第一，不要通过读取 timer.C 判断 AfterFunc 回调是否启动，因为函数式定时器的 C 不用于这次通知。第二，不要在 Stop 返回 false 后再次无条件调用同一个回调；这会制造重复业务。第三，如果使用的是 NewTimer，应围绕 t.C 的接收设计状态机，而不是套用 AfterFunc 的“回调已启动”结论。第四，Stop 与回调可能并发发生，释放共享资源前要让回调通过 done 或更具体的业务确认完成。

相关问题

Stop 返回 false 后还需要再 Stop 一次吗？ 不需要。它已经不能再次取消这次已到期的回调，重复调用不会提供“等待完成”的能力。

只想知道回调是否执行过，能不能只保留 started？ 可以，但要明确它只代表回调到达标记点；需要安全回收资源时仍应增加 done 或业务级完成信号。