time.Ticker用于周期性调度，启动后立即发送首个tick并按间隔重复；time.Timer仅单次触发，需Reset()复用但易丢事件；二者均须显式Stop()防泄漏，周期任务应for range ticker.C而非select读取。
Go 里 time.Ticker 和 time.Timer 根本不是一回事
别被名字骗了：time.Timer 只触发一次，time.Ticker 才是真·周期性调度。很多人写定时任务时直接用 Timer + 循环重置，结果漏掉时间点、goroutine 泄漏、甚至 panic —— 因为没调用 Stop() 或重复 Reset()。
典型错误现象：panic: send on closed channel（在已停止的 Ticker.C 上继续读）、CPU 占用飙升（for {} 空转未阻塞）、第一次执行延迟不准（误以为 time.AfterFunc 能替代 Ticker）。
-
time.NewTicker(d)启动后立即发送第一个 tick，之后每d时间发一次；想“延后首次执行”，得自己time.Sleep()一下再启 ticker -
time.NewTimer(d)是单次倒计时，触发后C关闭，必须Reset()才能复用；但Reset()在 timer 已触发或已Stop()时返回false，不处理就可能丢事件 - 所有
time.Ticker/time.Timer都要显式Stop()，尤其在长生命周期 goroutine 退出前，否则底层 ticker/timer 不释放，内存和 goroutine 持续累积
用 time.Ticker 做周期任务，别直接 select 读 C
直接 for range ticker.C 或 select { case 看似简单，但一旦任务执行时间超过 tick 间隔，就会积压、跳过、甚至并发冲突 —— <code>Ticker 不做节流，它只管按时发信号。
常见场景：每 5 秒拉一次接口，但某次网络超时花了 8 秒，下个 tick 到来瞬间又触发，导致两次请求并发跑，后端限流告警。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 安全做法是用带缓冲的 channel 或互斥控制，例如启动一个 goroutine 专门消费
ticker.C，收到信号后检查上一次任务是否完成（用sync.Mutex或atomic.Bool） - 更推荐用
time.AfterFunc+ 递归重调度：每次任务结束才安排下次，天然串行，避免堆积。缺点是无法严格对齐整点（比如每分钟 0 秒执行），但多数业务不需要那么精确 - 别用
time.Sleep()替代Ticker：sleep 不受 GC 影响，但精度差、不可中断；而Ticker的 channel 可被select中断，适合配合 context 取消
context.WithTimeout 和 ticker.Stop() 必须配对出现
很多服务启停逻辑里，只记得 ctx.Done() 监听，却忘了 stop ticker —— 导致进程退出时 ticker 还在后台发信号，引发 panic 或资源泄漏。
典型错误写法：go func() { for range ticker.C { /* ... */ } }()，没做任何取消机制；或者用 select { case 但漏掉 <code>ticker.Stop()。
- 正确姿势：在 goroutine 退出前调用
ticker.Stop()，且确保只调一次（Stop()是幂等的，但多次调也没坏处） - 如果用
context.WithCancel控制生命周期，建议把ticker包进 struct，实现Close()方法统一清理 - 注意：
ticker.Stop()不会关闭Cchannel，只是停止发送；已发送但未读取的 tick 仍可读到，所以select里要配合default或判断ok避免阻塞
需要精确到毫秒级调度？别硬刚 time.Ticker
time.Ticker 底层依赖系统时钟和调度器，Linux 下通常误差 ±10ms，Windows 更大；高负载时还可能漂移。如果你的任务要求“每秒整点执行”，靠 Ticker 对齐几乎不可能。
真实需求如：每分钟第 0 秒推送统计、每小时整点刷新缓存——这些本质是“基于 wall clock 的调度”，不是“固定间隔”。这时候 time.Ticker 就是错工具。
- 用
time.Until(nextScheduledTime)+time.Sleep()或time.AfterFunc()手动对齐，每次计算下一个绝对时间点 - 复杂场景直接上外部调度器，比如
robfig/cron（注意它默认用本地时区，UTC 场景要显式设cron.WithLocation(time.UTC)） - 别在
Ticker的 goroutine 里做耗时 I/O 或锁竞争，它应该只负责“发信号”，具体任务扔给 worker pool，否则整个 tick 链路卡死
最常被忽略的一点：Ticker 的时间精度和你的 GOMAXPROCS、GC 频率、系统负载强相关。压测时发现定时偏差变大，先看是不是 goroutine 调度被挤占了，而不是怀疑代码写错了。
