time.Ticker 高频创建会导致 goroutine 泄漏和定时器堆压力增大，应长期复用而非每秒新建；推荐用 time.AfterFunc+递归、sync.Pool 管理临时对象、慎用 cron 库做亚秒级调度，并严格管控 context 和 channel 生命周期。
为什么 time.Ticker 在高频场景下会拖慢程序
频繁创建和销毁 time.Ticker 实例（比如每秒启动一个新 ticker）会导致 goroutine 泄漏和定时器对象堆积，Go 运行时的定时器堆（timer heap）压力增大，最终表现为 CPU 升高、调度延迟变大。这不是 bug，而是误用：ticker 本意是长期复用的周期信号源，不是“每次任务都 new 一个”的工具。
- 避免在循环中反复调用
time.NewTicker()，尤其在 HTTP handler 或消息消费逻辑里 - 若需动态间隔，优先用
time.AfterFunc()+ 递归重调度，而非反复新建 ticker - 检查 pprof 输出中的
runtime.timerproc占比，超过 5% 就值得怀疑定时器使用是否合理
用 sync.Pool 管理定时任务中的临时对象
很多定时任务会在每次执行时分配切片、map 或结构体（比如解析日志、组装通知 payload），这些小对象看似无害，但在每秒数百次的频率下会显著增加 GC 压力。Go 的 sync.Pool 能有效缓解这个问题，但要注意生命周期管理。
- pool 中的对象不能持有外部引用（如闭包捕获长生命周期变量），否则造成内存泄漏
- 建议为每类任务定义专用 pool，例如：
var notifyPayloadPool = sync.Pool{New: func() interface{} { return &NotifyPayload{} }} - 用完必须显式归还：
defer notifyPayloadPool.Put(payload)，别依赖 GC
慎用 cron 库做毫秒级或亚秒级调度
像 robfig/cron 或 go-cron 这类基于字符串解析的库，内部通常依赖单个 ticker 驱动所有任务，再逐个比对时间表达式。当任务数超过 50 个，且存在大量 * * * * * ? 或 */10 * * * * ? 类型规则时，每次 tick 都要遍历全部规则——哪怕只是判断“该不该跑”，开销也不容忽视。
- 毫秒/百毫秒级调度直接用
time.AfterFunc()或time.Ticker更轻量 - 若必须用 cron 表达式，改用
github.com/robfig/cron/v3并启用cron.WithSeconds()，它内部做了规则分桶优化 - 避免在 cron job 里做阻塞操作（如同步 HTTP 请求、未设超时的 DB 查询），这会卡住整个调度线程
goroutine 泄漏比性能慢更危险
定时任务中最隐蔽的问题不是跑得慢，而是 goroutine 永远不退出。常见于：用 go fn() 启动协程但没处理 channel 关闭、HTTP client 超时不设、context 没传递或没监听 Done。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.NumGoroutine()定期打点，观察是否持续增长 - 所有异步调用必须绑定 context：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second) - channel 操作前先 select 判断 ctx.Done()，而不是直接写入或读取
高频定时任务的稳定性，往往取决于你有没有认真对待那几个被忽略的 cancel() 和 close() 调用。
