time.Ticker适用于严格周期任务，需手动Stop防止goroutine泄漏；time.AfterFunc用于延迟执行，两者均适合单机场景。
在 Go 中实现定时任务，最常用也最轻量的方式是 time.Ticker 和 time.AfterFunc。它们不依赖外部服务，适合单机场景下的周期性任务（如轮询、清理、心跳）或延迟执行（如延时重试、超时回调）。关键在于理解两者的适用边界和资源管理细节。
用 Ticker 实现稳定周期任务
time.Ticker 适用于需要严格按固定间隔重复执行的任务，比如每 5 秒检查一次配置文件、每分钟上报一次指标。它内部使用一个后台 goroutine 持续发送时间信号到通道，因此必须手动调用 ticker.Stop() 防止 goroutine 泄漏。
- 创建后立即开始计时，第一次触发在
interval后，不是“立刻+interval” - 任务执行时间若超过间隔，下一次触发会“堆积”——
Ticker不跳过，而是尽快连续触发（除非你手动跳过） - 推荐在循环中用
select配合ctx.Done()实现可取消的定时任务
示例：每 3 秒打印一次，支持优雅停止
ticker := time.NewTicker(3 * time.Second)defer ticker.Stop()
for {
select {
case fmt.Println("执行定时任务")
case return // 退出循环
}
}
用 AfterFunc 实现单次延迟执行
time.AfterFunc 是启动一个延迟后只执行一次的函数，底层基于 time.Timer，适合做延时重试、超时清理、异步回调等。它返回一个 *Timer，可通过 Stop() 取消未触发的任务，避免误执行。
立即学习“go语言免费学习笔记（深入）”；
- 如果任务函数执行耗时较长，不会影响其他逻辑，因为它是独立 goroutine 执行
- 多次调用
AfterFunc会创建多个 timer，记得保存并管理（尤其在循环或高频事件中） - 不能直接“重启”，需先
Stop()再新建；如需周期性+可取消，优先选Ticker
示例：3 秒后发送告警，但可在之前取消
sendAlert()
)
// ...
if shouldCancel {
timer.Stop() // 返回 true 表示成功取消
}
避免常见陷阱
两类定时器都容易因忽略生命周期导致内存泄漏或逻辑错误：
- 忘记 Stop：Ticker/Timer 不会自动释放，长期运行的服务中积累大量 goroutine 和 channel
- 在循环里反复 NewTicker：每次新建都会起新 goroutine，旧的没 Stop 就变成僵尸
-
任务 panic 未捕获：Ticker 循环中 panic 会导致整个 goroutine 崩溃且无提示，建议用
recover包裹任务体 - 用 time.Sleep 模拟定时：不可靠，无法响应中断，也不支持并发安全的取消
简单封装提升复用性
对常用模式可做薄封装，比如带上下文取消和 panic 恢复的周期执行：
func RunEvery(ctx context.Context, d time.Duration, f func()) {ticker := time.NewTicker(d)
defer ticker.Stop()
for {
select {
case defer func() {
if r := recover(); r != nil {
log.Printf("task panic: %v", r)
}
}()
f()
case return
}
}
}
调用：RunEvery(ctx, 10*time.Second, doBackup) —— 简洁、可控、健壮。
基本上就这些。Ticker 和 AfterFunc 足够覆盖大多数本地定时需求，不复杂但容易忽略 Stop 和错误处理。用好它们，比引入 cron 库或消息队列更轻量也更可控。
