用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()
<p>for {
select {
case <-ticker.C:
go func() {
// 这里放实际任务逻辑
doSomething()
}()
}
}用 robfig/cron/v3 处理 cron 表达式与单机多任务管理
需要按“每天凌晨2点”“每周一上午9点”这类语义调度？robfig/cron/v3 是当前 Go 生态最稳定的 cron 库，支持标准 cron 格式、秒级精度（加前导字段）、任务名称标记和基础运行统计。
立即学习“go语言免费学习笔记（深入）”；
关键点：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
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，各工作节点消费执行——适合高可靠、可追溯、需重试的业务
注意：不要用本地文件或数据库行锁做分布式协调，网络分区或事务异常时极易出现脑裂或死锁。
真正麻烦的不是“怎么让任务跑起来”，而是“怎么确保它只跑一次、失败能恢复、变更可灰度、执行可审计”。这些边界问题，往往在压测或上线后才暴露。
