time.Ticker仅周期性发信号，不保证任务完成才触发下一次；正确做法是加互斥锁防重入，任务超时需主动跳过；严格整秒对齐应手动计算时间点+AfterFunc递归调度。
用 time.Ticker 实现稳定秒级触发，但别直接拿它做“定时执行”
秒级任务最常见误区是把 time.Ticker 当成“到点就跑一次”的调度器。它本质是**周期性发信号**，不保证执行完成才发下一次。如果任务耗时 >1s，就会堆积 goroutine 或漏 tick。
正确做法是用 time.Ticker 控制节奏，但每次收到 tick 后先检查上一次任务是否结束，再决定是否启动新任务：
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
<p>var mu sync.Mutex
var running bool</p><p>for range ticker.C {
mu.Lock()
if !running {
running = true
mu.Unlock()
go func() {
defer func() {
mu.Lock()
running = false
mu.Unlock()
}()
doWork() // 你的实际任务
}()
} else {
mu.Unlock()
// 可选：打日志或 metrics 记录“被跳过”
}
}- 用
sync.Mutex防止并发重入，比 channel 更轻量且可控 - 不要在主循环里直接调用
doWork()—— 阻塞会拖垮整个 ticker - 如果任务必须严格按秒对齐（比如每整秒上报），需用
time.Now().Truncate(1*time.Second).Add(1*time.Second)算下次触发时间，再配合time.AfterFunc
需要精确对齐系统秒（如 00:00:00、00:00:01）？用 time.AfterFunc + 递归重置
当任务要严格落在整秒时刻（比如监控程序每秒初采集一次 CPU），time.Ticker 的初始偏移不可控，且无法动态校准。这时应手动计算下一个整秒时间点，用 time.AfterFunc 触发，并在任务末尾重新调度：
func scheduleAtNextSecond() {
now := time.Now()
next := now.Truncate(1 * time.Second).Add(1 * time.Second)
time.AfterFunc(next.Sub(now), func() {
doWork()
scheduleAtNextSecond() // 递归调度下一次
})
}- 注意
next.Sub(now)可能为负（当前已过目标时间），此时应设为0或略加1ms避免立即触发 - 递归调用不会栈溢出，因为
AfterFunc是异步的，函数当场返回 - 这种写法天然规避了 ticker 积压问题，但也意味着如果
doWork()耗时 >1s，下一次仍会在整秒时刻触发——你要自己判断是否跳过
并发多任务 + 秒级精度？别硬扛，换 robfig/cron/v3 并禁用秒字段
原生 cron 库默认最小粒度是分钟，但 robfig/cron/v3 支持秒级表达式（如 "* * * * * *"）。不过它底层仍是基于 time.Timer 队列，高频率下有调度延迟和内存开销。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如果你已有多个不同周期的任务（如 1s、5s、30s），又不想自己维护多 ticker，可以这样用：
c := cron.New(cron.WithSeconds()) // 必须显式启用秒支持
c.AddFunc("*/1 * * * * *", func() { doWork() }) // 每秒执行
c.AddFunc("*/5 * * * * *", func() { doOtherWork() })
c.Start()
// 记得 defer c.Stop()- 务必调用
cron.WithSeconds()，否则"* * * * * *"会被当作 6 字段非法表达式报错 - 每个任务单独 goroutine 执行，不相互阻塞，但要注意全局并发数 —— 默认无限制，大量任务可能打满 CPU
- 它不解决“任务超时是否跳过”的逻辑，这部分仍需你在
doWork内部加超时或状态锁
为什么不用 time.Sleep 循环？因为误差会滚雪球
有人写 for { doWork(); time.Sleep(1*time.Second) }，看似简单，实则危险：
- 每次
doWork()耗时波动（哪怕只是几毫秒），sleep 时间就少几毫秒，长期运行后整点漂移可达秒级 - 进程暂停（如 GC STW、系统休眠）会导致 sleep 延迟远超预期，下次执行直接“迟到”
- 无法响应中断（
ctx.Done()），必须靠共享变量+break，难维护
真正需要“固定间隔”而非“固定时刻”的场景极少；绝大多数秒级任务关心的是节奏稳定性，不是绝对时间戳 —— 这正是 time.Ticker 的设计本意，只是要用对方式。
最容易被忽略的一点：无论用哪种方式，都要在任务内部处理 panic。goroutine 崩溃不会终止 ticker 或 cron，后续 tick 仍会不断触发，直到资源耗尽。
