该用 time.Ticker 还是 time.Timer 取决于任务类型：周期性触发用 Ticker（须手动 Stop），单次延迟用 Timer（自动销毁）；务必结合 context 控制生命周期，避免 goroutine 泄漏和内存暴涨。
Go 语言里 time.Ticker 和 time.Timer 到底该用哪个？
多数人一开始写定时任务，直接上 time.Tick 或 time.NewTicker，结果发现程序跑着跑着内存涨、goroutine 泄漏、甚至 panic。根本原因：没分清「周期性触发」和「单次延迟执行」的语义差异。
time.Ticker 适合固定间隔轮询（比如每 5 秒查一次健康状态），但必须手动 Stop()，否则底层 goroutine 永不退出；time.Timer 是一次性倒计时，触发后自动销毁，想重复用就得重建。
- 需要「每隔 N 秒执行一次」→ 用
time.NewTicker，且务必在不再需要时调用ticker.Stop() - 需要「N 秒后执行一次」或「N 秒后执行，再延后 M 秒再执行」→ 用
time.NewTimer或time.AfterFunc - 千万别在 for 循环里反复
time.After()而不接收 channel → 会堆积大量未读 channel，引发内存泄漏
用 context.Context 安全控制定时器生命周期
硬编码 time.Sleep 或裸用 time.Ticker 最大的问题是：没法优雅退出。服务关闭时，正在运行的 ticker 若没被 Stop，会卡住 main 函数退出，或导致 goroutine 残留。
正确做法是把定时逻辑包进一个函数，并接受 context.Context，利用 ctx.Done() 触发清理：
立即学习“go语言免费学习笔记（深入）”；
func runPeriodicJob(ctx context.Context, interval time.Duration) {
ticker := time.NewTicker(interval)
defer ticker.Stop()
<pre class='brush:php;toolbar:false;'>for {
select {
case <-ticker.C:
// 执行实际任务
doSomething()
case <-ctx.Done():
return // 上级主动取消，立即退出
}
}}
启动时传入带超时或可取消的 context，比如 context.WithCancel(parentCtx)，关停时调 cancel() 即可。
- 不要在
select外层用for range ticker.C—— 这种写法无法响应 cancel - 如果任务执行时间可能超过 interval，考虑用
time.AfterFunc+ 递归调度，避免堆积 - 高频任务（如
第三方库 robfig/cron 的真实适用场景
很多人一上来就引入 github.com/robfig/cron/v3，以为能替代所有定时需求。但它本质是「基于字符串表达式的 job 调度器」，不是底层定时原语的封装。
它适合：需要 cron 表达式（"0 */2 * * *" ）、多个异构任务统一管理、支持 job 日志/错误重试/并发控制等运维能力的场景。不适合：极简嵌入、无依赖要求、或需与 context 深度集成的模块。
- 默认使用
cron.WithSeconds()才支持秒级精度（v3 默认从分钟开始） -
cron.AddFunc注册的任务 panic 会导致整个调度器 halt，必须自行 recover - 若只需「每 30 秒拉一次 API」，用两行
time.Ticker更轻量、更可控
生产环境必须加的三道防线
本地跑通 ≠ 上线稳定。Go 定时任务在线上常因时区、时钟跳变、panic 传播等问题静默失败。
- 所有定时任务入口加
recover()，防止单个 panic 停掉整个 ticker：func safeJob() { defer func() { if r := recover(); r != nil { log.Printf("job panicked: %v", r) } }() doSomething() } - 避免依赖本地系统时钟 —— 用
time.Now().UTC()统一时区，尤其跨地域部署时 - 对关键任务加「执行时间监控」：记录每次开始/结束时间，超时则告警（比如 HTTP 请求 >5s 就标记异常）
最易被忽略的是：Ticker 的 C channel 在 Stop 后仍可能有残留值，所以 select 中一定要优先处理 ctx.Done()，而不是靠 default 或顺序判断。
