应使用time.Ticker配合goroutine执行业务逻辑以避免阻塞；robfig/cron/v3需启用cron.WithSeconds()支持秒级调度，多任务应共用同一实例并手动recover防止panic导致调度中断。
用 time.Ticker 做固定间隔任务，但别在循环里直接写业务逻辑
Go 里最轻量的定时调度就是 time.Ticker，但它不是“任务调度器”，只是个时间信号发生器。常见错误是把耗时操作（比如 HTTP 请求、数据库写入）直接塞进 for range ticker.C 循环里——这会阻塞下一个 tick，导致实际执行间隔严重漂移。
正确做法是启动 goroutine 处理业务：
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop()
<p>for range ticker.C {
go func() {
// 这里放你的实际逻辑，比如调用 <code>processJob()</code>
processJob()
}()
}注意：如果 processJob() 可能并发冲突（比如共用全局变量或文件句柄），得加锁或改用带缓冲的 channel 控制并发数。
robfig/cron/v3 是生产级首选，但默认不支持秒级精度
官方 time.Ticker 不适合复杂调度（如 “每周一 9:00 执行”），这时该上 robfig/cron/v3。它语法兼容 Unix cron，但 v3 版本默认最小粒度是分钟——想实现秒级（如 "*/5 * * * * *"），必须显式启用秒字段：
立即学习“go语言免费学习笔记（深入）”；
- 初始化时传入
cron.WithSeconds()选项 - 表达式必须是 6 字段（秒 分 时 日 月 周），不能少
- 没加
WithSeconds()却写了 6 字段，会静默失败，只按 5 字段解析（秒被忽略）
示例：
c := cron.New(cron.WithSeconds())
c.AddFunc("*/5 * * * * *", func() { log.Println("每5秒执行") })
c.Start()多个定时任务共用一个 cron 实例，别每个任务都 new 一个
每个 cron.New() 都起独立的 goroutine 和 timer 系统调用，资源开销不小。多个任务（比如健康检查 + 数据清理 + 缓存刷新）应该共享同一个 cron 实例：
- 统一管理启停：
c.Start()/c.Stop()覆盖全部任务 - 避免重复初始化导致 timer 冲突或 panic
- 如果某任务需单独控制生命周期（比如动态启停），改用
c.AddJob()+ 自定义cron.Job接口，而不是 new 新实例
别写成这样：
// ❌ 错误：每个任务都 new，难维护还可能泄漏
cron.New().AddFunc("@every 10s", f1).Start()
cron.New().AddFunc("@daily", f2).Start()任务 panic 会导致整个 cron 实例停止，必须 recover
robfig/cron 默认不捕获 job 内部 panic，一旦某个任务 panic，整个调度器就卡住，后续所有任务都不再触发——这点和很多人直觉相反。
安全写法是在任务函数里手动 recover：
c.AddFunc("@hourly", func() {
defer func() {
if r := recover(); r != nil {
log.Printf("job panicked: %v", r)
}
}()
riskyOperation() // 可能 panic 的代码
})更彻底的做法是封装一层通用 wrapper，避免每个 AddFunc 都重复写 defer；但要注意 wrapper 不能掩盖真正需要暴露的错误（比如数据库连接失败应告警，而非静默吞掉）。
真实场景里，最容易被忽略的是 panic 吞掉后日志没打全、没带上堆栈，导致问题难以定位——至少要用 log.Printf("%+v", r) 或 fmt.Sprintf("%+v", r) 输出完整 panic 信息。
