Timer 用完不重置，下次 Reset() 就会 panic
Go 的 time.Timer 是一次性触发的，触发后内部状态就变成 “已停止”，再调 Reset() 前必须确保它没在运行、也没被 Stop() 过但没触发——否则会 panic：panic: timer already fired or stopped。
常见错误是：在 goroutine 中反复 Reset() 却没处理好竞态，比如多个 goroutine 同时操作同一个 Timer，或在 select 收到 timer.C 后忘了重新 Reset()。
- 安全做法：每次从
timer.C收到信号后，立刻Reset()新时间；若需取消，先Stop()再丢弃 - 别复用已触发的
Timer：触发后timer.C会永久关闭，Reset()不会重建 channel - 更稳妥的替代：用
time.AfterFunc()+ 递归调用，或直接换Ticker（如果确实是周期性）
Ticker 在高频率下可能堆积 goroutine，Stop() 不及时就泄漏
time.Ticker 每次触发都会向 ticker.C 发送一个 time.Time，但如果接收端阻塞或处理慢，channel 缓冲区（长度为 1）很快填满，后续 tick 会被丢弃——但 goroutine 本身不会停，它还在后台拼命发，只是发不出去。
这容易被误以为“任务卡住”，其实是 Ticker 在默默吃 CPU，同时 goroutine 持续存活，导致内存和 goroutine 数缓慢上涨。
立即学习“go语言免费学习笔记（深入）”；
- 务必在不用时显式调
ticker.Stop()，尤其在循环中创建又未清理的场景 - 避免在
for range ticker.C外部做耗时操作；若处理逻辑可能阻塞，用带超时的select或另起 goroutine 分流 - 不要用
time.Sleep()替代Ticker做周期任务——它无法被外部中断，也不适合精确间隔
定时器精度受系统调度和 GC 影响，time.Now().Add() 算错就偏移
Go 定时器底层依赖系统时钟和 runtime 调度器，实际触发时间可能比设定晚几毫秒到几十毫秒。更隐蔽的问题是：很多人用 time.Now().Add(5 * time.Second) 算下次触发时间，但这个“现在”是调用时刻，而真正执行到 Reset() 可能已过去几 ms，导致周期悄悄漂移。
比如想每 5 秒固定触发一次（类似 cron 的“第 0、5、10… 秒”），用相对计算就会越积越偏。
- 需要对齐固定时间点（如整秒、整分）时，用
time.Truncate()+Add()算下一个整点，而不是基于上次触发时间累加 - 对精度要求高的场景（如金融 tick 推送），别依赖单个
Timer链式重置，改用Ticker+ 外部校准逻辑 - GC STW 期间所有定时器暂停，短于 10ms 的间隔基本不可靠；生产环境建议最低设为 20ms 以上
并发读写 Timer/Ticker 必须加锁，time.AfterFunc() 是唯一无锁安全选项
Timer 和 Ticker 的方法（Reset()、Stop()、C 字段）都不是并发安全的。多个 goroutine 同时调 Reset() 或一边 Stop() 一边从 C 读，会引发 panic 或未定义行为。
但 time.AfterFunc() 是例外：它内部封装了 goroutine 启动和函数调用，调用者只需传入函数，无需管理生命周期，天然规避了并发操作对象的问题。
- 若任务简单、无需中途取消，优先用
time.AfterFunc(d, f)；要取消？那就得自己维护一个sync.Once或atomic.Bool控制函数是否执行 - 真要共享
Timer，用sync.Mutex包裹Reset()/Stop()；别图省事用atomic.Value存*time.Timer——它不解决方法调用的并发问题 -
Ticker几乎不该跨 goroutine 共享；每个需要周期事件的逻辑，应自己创建并管理自己的Ticker
定时器不是“设置完就不管”的黑盒，它的生命周期、重置时机、触发上下文，全得你亲手掐着点管。稍一松手，漏掉的不只是时间，还有 goroutine 和内存。
