应使用 cron/v3 处理表达式驱动调度，它支持秒级语法、防漂移、panic 恢复与并发控制；非固定间隔任务宜用 time.timer 单次触发+动态计算下一次时间；万级任务需时间轮降本增效；所有定时器必须配 context 取消与 stop() 防泄漏。
用 cron/v3 处理表达式驱动的常规调度
如果你的任务是“每天 9:00 发邮件”“每 5 分钟拉一次指标”，直接用 time.Ticker 是错的——它只管发信号，不解析时间语义，也不防漂移、不重试、不兜底。真正该上的是 github.com/robfig/cron/v3。
它默认支持秒级（6 字段），写 "0 0 9 * * *" 表示每天 9:00:00；若沿用传统 5 字段，得显式传 cron.WithParser(cron.NewParser(cron.Minute | cron.Hour | cron.Dom | cron.Month | cron.Dow))。
- 任务 panic 不会中断整个调度器，默认 log 后继续下一轮
- 不自动持久化：进程重启后任务丢失，需配合数据库记录
last_run做幂等判断 - 并发控制靠
cron.WithChain(cron.Recover(), cron.DelayIfStillRunning())，避免前次未结束就触发下一次
用 time.Timer 实现单次+自计算的精准对齐
遇到“每月第一个周一上午 10 点”这类非固定间隔任务，time.Ticker 的固定 tick 机制反而拖累性能：每分钟 tick 一次再判断日期，既浪费又易出错。
更稳的做法是每次执行完，立刻算出下一个合法时间点，用 time.Timer 单次触发：
- 用
nextTime := t.AddDate(0, 0, 7)或nextTime.Weekday() == time.Monday推导下个时间 - 调用
timer.Reset(nextTime.Sub(time.Now()))安排下次；注意Reset()在已触发或已Stop()时返回false，必须检查 - 别在 timer 触发后忘记
Stop()，否则底层资源泄漏
用时间轮（TimeWheel）扛住万级任务吞吐
当定时任务数超过几千，且要求低延迟、高吞吐（比如 IM 消息超时撤回、连接空闲踢出），time.Timer 和 cron/v3 都会因每个任务独占一个 goroutine 或 channel 而内存暴涨、GC 压力大。
这时应引入时间轮实现，核心是把时间切片成槽位，任务按延迟归入对应 slot，指针扫到即触发：
- 添加/删除/触发都是
O(1)，内存占用与任务数几乎无关 - 主流开源实现如
github.com/RichardKnop/machinery/v2或自研timewheel包，需关注其是否支持动态扩容（slot 数固定则无法应对突发任务潮） - 注意时间轮基于单调时钟，不响应系统时间跳变；若业务强依赖墙钟（如财务结算），仍得兜底校验
time.Now()
goroutine 泄漏和 context 取消必须配对处理
所有基于 time.Ticker 或 time.Timer 的长期运行调度，都面临一个隐形陷阱：没正确释放资源。常见错误包括：
- 在
select中监听ticker.C却漏掉ticker.Stop()，导致进程退出后 ticker 仍在后台发信号，引发panic: send on closed channel - 用
for range ticker.C但没结合context.Context，服务 reload 时无法优雅退出 - 任务函数内启 goroutine 但未设超时或未回收，造成堆积
正确姿势是：启动 goroutine 时传入 ctx，在 select 中同时监听 ctx.Done() 和 ticker.C，退出前统一 defer ticker.Stop()。复杂调度器里，这个取消链路往往比任务逻辑本身更难写对。
