time.Timer 和 time.Ticker 仅为底层计时原语，不具备任务调度能力；正确方案应选用 cron/v3 等表达式驱动库，并针对失败重试、重复执行、时间漂移做兜底处理。
Go 的 time.Timer 和 time.Ticker 不是调度器，只是基础计时原语
很多人一上来就用 time.NewTimer 或 time.NewTicker 做“定时任务”，结果发现：任务不准、漏执行、goroutine 泄漏、重启后不恢复。这是因为它们只负责“到点通知一次/周期性通知”，不管理任务生命周期、不处理失败重试、不支持持久化或分布式协调。
如果你要的是“每天上午 9 点发邮件”“每 5 分钟拉一次监控数据”，time.Ticker 无法直接满足——它只能每 5 分钟 tick 一次，但你得自己判断当前时间是否符合“整点 + 偏移”逻辑，还得手动对齐、容错、防重复。
-
time.Timer是单次触发，触发后必须显式调用Reset()才能复用；忘记Reset()或在已触发状态下调用会 panic -
time.Ticker是周期性通道发送，停止必须调用Stop()，否则 goroutine 和 channel 会一直存活，导致内存泄漏 - 二者都基于系统单调时钟，不响应系统时间跳变（如 NTP 校正），所以用
time.Now().Hour() == 9做日触发，可能因校时错过或重复
用 cron 包实现表达式驱动的定时任务（推荐入门方案）
真正接近 Unix cron 行为的 Go 实现，首选 github.com/robfig/cron/v3。它解析 * * * * * 表达式、自动对齐到最近合法时间点、支持任务并发控制和 panic 捕获。
注意：v3 版本默认使用 Seconds 级别（6 字段），如果沿用传统 5 字段写法，要显式指定选项：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
import "github.com/robfig/cron/v3"
<p>c := cron.New(cron.WithSeconds()) // 启用秒级支持
// 或用 cron.WithParser(cron.NewParser(cron.Minute | cron.Hour | cron.Dom | cron.Month | cron.Dow))
c.AddFunc("0 0 9 <em> </em> <em>", func() { /</em> 每天 9:00:00 */ })
c.Start()
- 表达式字段顺序是：
秒 分 时 日 月 周（启用WithSeconds()后），不是系统 cron 的 5 字段 - 任务函数内 panic 不会导致整个 cron 停摆，默认会 log 并继续下一次调度
- 不支持任务持久化：进程退出即丢失；需配合外部存储（如数据库标记 last_run）做幂等控制
自定义调度需绕开 time.Ticker 的“固定间隔”陷阱
如果业务要求“每月第一个周一上午 10 点执行”，靠 time.Ticker 每分钟 tick 一次再判断日期，既低效又容易出错。更稳的方式是：每次执行完，计算下一个合法时间点，用 time.Timer 单次触发。
关键点在于用 time.Time.AddDate()、time.Time.Weekday() 等方法算出下次时间，而不是依赖固定周期：
func nextFirstMonday(t time.Time) time.Time {
y, m, _ := t.Date()
firstDay := time.Date(y, m, 1, 10, 0, 0, 0, t.Location())
for firstDay.Weekday() != time.Monday {
firstDay = firstDay.AddDate(0, 0, 1)
}
return firstDay
}
<p>timer := time.NewTimer(nextFirstMonday(time.Now()).Sub(time.Now()))
go func() {
<-timer.C
doTask()
// 重新计算并重置
timer.Reset(nextFirstMonday(time.Now()).Sub(time.Now()))
}()
- 每次
Reset()前必须确保 timer 已触发或已Stop()，否则会 panic - 计算下次时间时，务必传入原始
time.Time对象的Location()，否则跨时区会错乱 - 这种模式适合低频、逻辑复杂的调度；高频任务（如每秒）仍建议用
time.Ticker+ 条件过滤
生产环境必须考虑任务失败、重复、漂移这三件事
哪怕用了 cron 包，只要任务体涉及网络请求、数据库写入、文件操作，就一定会遇到超时、冲突、时钟漂移。没有自动兜底机制的任务调度等于裸奔。
- 失败重试：cron 默认不重试，需在任务函数内封装
for循环 + 指数退避，或用github.com/hibiken/asynq这类带重试队列的方案 - 重复执行：同一任务在多实例部署下可能被多个进程同时触发，需加分布式锁（Redis SETNX）或数据库唯一约束（如插入带
task_name + date复合唯一索引的记录） - 时间漂移：Linux 容器中
/proc/sys/kernel/timer_migration可能导致time.Now()在 CPU 迁移后短暂回跳，用time.Now().UnixNano()做幂等标记时要注意
最常被忽略的是：认为“调度准时 = 任务准时”。其实从 timer 触发、到 goroutine 被调度、再到任务真正开始执行，中间有不可控延迟。高精度场景必须在任务体内检查当前时间是否仍在预期窗口内，超时则主动放弃。
