用time.Ticker适合轻量周期任务，但需goroutine避免阻塞；robfig/cron/v3支持cron表达式和秒级调度，需显式启用秒级并自行recover；自研调度器易引发并发、内存泄漏等问题；跨机调度须用分布式锁或消息队列。

用 time.Ticker 实现简单周期任务，但别直接上生产

如果只是每 5 秒打印一次日志、或轮询某个本地状态，time.Ticker 足够轻量且可控。它不依赖外部服务，启动快，无额外依赖。

但要注意：time.Ticker 是纯内存级调度，进程退出即失效；不支持任务持久化、失败重试、分布式协调。一旦程序 panic 或被 kill，任务就彻底消失。

常见误用是把耗时操作（如 HTTP 请求、数据库写入）直接塞进 ticker.C 的 for 循环里，导致下一轮 tick 被阻塞——必须用 goroutine 包裹：

ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
go func() {
// 这里放实际任务逻辑
doSomething()
}()
}
}

用 robfig/cron/v3 处理 cron 表达式与单机多任务管理

需要按“每天凌晨2点”“每周一上午9点”这类语义调度？robfig/cron/v3 是当前 Go 生态最稳定的 cron 库，支持标准 cron 格式、秒级精度（加前导字段）、任务名称标记和基础运行统计。

关键点：

• cron.New(cron.WithSeconds()) 必须显式启用秒级支持，否则默认从分钟开始解析
• 每个 cron.AddFunc() 注册的任务，底层共享同一个系统 timer，高频率任务（如 * * * * * *）可能挤压其他任务执行时机
• 任务 panic 不会终止整个 cron 实例，但错误会被吞掉——建议在任务函数内 recover 并记录日志
• 不支持任务暂停/启用切换，增删任务需调用 cron.Stop() + cron.Start() 重建，期间有短暂窗口丢失触发

为什么别自己封装 “定时器 + map[taskID]func()” 管理任务

看似灵活，实则埋坑密集：

• 并发安全：多个 goroutine 同时增删 map 会 panic，必须加 sync.RWMutex，但锁粒度难把握——锁太粗影响吞吐，太细易漏保护
• 生命周期混乱：任务函数引用了闭包变量，而该变量所属对象已释放，导致静默内存泄漏或 panic
• 无执行上下文：无法统一控制超时（context.WithTimeout）、取消（ctx.Done()）、重试策略
• 调试困难：没有任务 ID、注册时间、最近执行时间等元信息，出问题只能翻日志猜

已有成熟库（如 gocron、asynq）已覆盖这些细节，重复造轮子成本远高于学习接入成本。

跨机器任务调度必须引入消息队列或分布式锁

单机 cron 在多实例部署时会重复执行同一任务（比如两个 API 实例都触发“每日数据归档”），这不是 bug，是设计使然。

解法只有两类：

• 用 Redis 分布式锁（SET key value NX PX 10000）包装任务入口，抢到锁的实例才执行——适合低频、非强一致场景
• 把任务转为异步消息：由一个中心调度器（可基于 asynq 或自研）按计划推送到 Redis / Kafka，各工作节点消费执行——适合高可靠、可追溯、需重试的业务

注意：不要用本地文件或数据库行锁做分布式协调，网络分区或事务异常时极易出现脑裂或死锁。

真正麻烦的不是“怎么让任务跑起来”，而是“怎么确保它只跑一次、失败能恢复、变更可灰度、执行可审计”。这些边界问题，往往在压测或上线后才暴露。