go定时调度需手动选库配参防坑，time.ticker非调度器，robfig/cron/v3须显式start、设时区、加中间件，http/db须复用，防并发写共享状态，热更新需安全替换逻辑。
Go 没有“框架级定时调度”——所谓“Golang框架定时”，本质是选对库、配对参数、防住坑，而不是套个框架就自动靠谱。
为什么 time.Ticker 不是定时任务调度器
time.Ticker 只是一个带缓冲 channel 的周期信号发生器，它不判断时间点、不防重、不处理 panic、不支持表达式。你写 for range ticker.C 直接调函数，一旦 doWork() 耗时超过间隔（比如 5 秒任务跑了 6 秒），下一个 tick 就被丢弃；如果没加 defer ticker.Stop()，进程退出后 goroutine 还在后台跑，pprof 里能看到一堆 runtime.timerproc。
- 它启动后立即发第一个 tick，想“启动后 10 秒再开始”，得先
time.Sleep(10 * time.Second) -
Ticker.C缓冲区长度为 1，阻塞读会导致后续信号丢失 - 不做并发控制，多个 tick 同时触发
doWork()，可能并发写同一份数据 - 系统时间跳变（如 NTP 校正）不影响
Ticker，但用time.Now().Hour() == 9做日触发会出错
robfig/cron/v3 初始化必须显式三件事
直接 cron.New() 创建的调度器默认是暂停态，不 Start() 就等于没开；主 goroutine 退出进程就结束，必须阻塞住；时区不指定，time.Local 在容器里大概率 panic “invalid time zone”。
- 启用秒级支持：用
cron.New(cron.WithSeconds())，否则"0 */5 * * * *"会被截成"*/5 * * * *"（每分钟执行） - 固定时区：推荐
cron.New(cron.WithLocation(time.UTC))，或cron.WithLocation(time.FixedZone("CST", 8*60*60))，别依赖time.Local - 加链式中间件：
cron.WithChain(cron.Recover(), cron.SkipIfStillRunning())，否则一次 panic 整个调度停摆 - 任务函数签名只能是
func()，闭包捕获循环变量会出 bug，需用cron.FuncJob或提前绑定参数
HTTP/DB 调用必须复用，否则线上必崩
定时任务里每次新建 http.Client 或 sql.Open，不出三天 fd 耗尽、连接池打满、超时堆积。这不是调度逻辑的问题，是资源管理漏了。
- HTTP 客户端：全局复用
&http.Client{Timeout: 10 * time.Second}，别用http.DefaultClient（无超时） - 数据库连接：
*sql.DB必须服务启动时初始化并复用，禁止在任务函数里sql.Open - 防并发写共享状态：多个任务更新同一个计数器？加
sync.Mutex或改用atomic.Int64 - 日志：cron/v3 默认静默失败，建议包装一层
log.Printf或换用gocron.WithLogger
热更新配置不是 reload 一句代码的事
把 "0 0 9 * * *" 写死在代码里，等于放弃运维能力。真要热更新，得靠外部驱动 + 安全替换逻辑，否则任务空窗、重复注册、并发冲突都可能发生。
- 表达式存在 Redis 或 etcd，另起 goroutine 定期轮询比对变更
- 监听文件变化（
fsnotify），读到新配置后先c.Remove(id)，再c.AddFunc(...)—— 这两个操作非并发安全，得加锁 - 更稳妥做法：维护一个注册表 map[string]func()，reload 时只替换函数体，避免 Stop/Start 带来的调度间隙
- 别用反射改 cron 内部字段，v3 不保证兼容性，升级就挂
真正难的从来不是“怎么让代码每 5 秒跑一次”，而是“怎么确保它每次只跑一次、不卡死、不泄漏、不误判时间、不被系统时钟带偏、出错有人知道”。这些细节藏在初始化参数、资源复用方式、并发控制粒度和热更新路径里，漏掉任何一环，线上都可能静默失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
