Go 的 time.Timer 是一次性定时器，复用前必须 Stop() 后再 Reset()，且仅当 Stop() 返回 true 时才安全；否则应新建 Timer 或改用 AfterFunc/Ticker。
Go 的 time.Timer 不能直接重置，复用前必须 Stop() + Reset()
很多人以为 Reset() 是“重新设置时间后继续用”，其实它隐含一个前提：Timer 必须处于**未触发且未被回收状态**。如果 Timer 已触发（即 C 通道已关闭或已被读取），再调 Reset() 会 panic；如果没 Stop() 就直接 Reset()，还可能漏掉上一次的触发信号。
常见错误现象：panic: send on closed channel 或定时器“偶尔不触发”“触发两次”。本质是没处理好 Timer 生命周期——它是一次性的，不是可配置的闹钟。
- 必须先检查
timer.Stop()返回值：若返回false，说明 timer 已触发，此时需从timer.C中尝试读取（避免 goroutine 阻塞） -
Reset()只在Stop()成功后才安全调用；否则应新建一个time.NewTimer() - 别在多个 goroutine 里并发调
Reset()，Timer 不是线程安全的
用 time.AfterFunc() 替代频繁创建 time.Timer 更轻量
如果你只是想“延迟执行一段逻辑”，且不需要手动控制取消或重设，time.AfterFunc() 比手管 time.Timer 更省心、更省内存。它内部做了封装，避免了用户误操作 Stop()/Reset() 的风险，也省去了 channel 接收逻辑。
使用场景：心跳超时回调、异步任务延时清理、简单重试退避（如失败后 1s 重试）。
立即学习“go语言免费学习笔记（深入）”；
-
time.AfterFunc()返回一个*time.Timer，同样支持Stop()，但你通常只需要它返回的句柄来取消 - 它不暴露
C通道，所以不会出现“忘记读 channel 导致 goroutine 泄漏” - 性能上，它和
time.NewTimer()底层共享同一套定时器堆，没有额外开销
示例：
t := time.AfterFunc(5*time.Second, func() { log.Println("timeout!") }) // 后续可 t.Stop()
高频重置场景下，用 time.Ticker + 状态标记比反复 Reset() 更稳
比如实现“用户活跃检测”：每次收到请求就重置 30s 超时。如果每秒有上百请求，频繁 Stop()+Reset() 不仅逻辑易错，还会让 runtime 定时器堆频繁调整，影响调度效率。
这时不如启动一个固定间隔的 time.Ticker（如 1s tick），用一个原子变量或 mutex 保护的字段记录“最后活跃时间”，每次 tick 时判断是否超时。这样 Timer 只启动一次，无生命周期管理负担。
-
time.Ticker是可长期复用的，不用每次重置；它本身不 panic，也不依赖Stop()是否成功 - 注意：不要在 ticker loop 里做阻塞操作，否则会拖慢整个 tick 周期
- 如果精度要求高（比如必须严格 30s 而非“30s 内某次 tick 判断”），那还是得用
Timer，但要接受它的单次语义
别忽略 time.Timer 的 GC 友好性：不用就让它被回收
有人为了“复用”，把 time.Timer 存在全局 map 或 struct 字段里长期持有，结果发现内存缓慢上涨。这是因为即使 Stop() 了，Timer 内部仍持有 goroutine 和 channel 引用，直到它被 GC 回收——而只要还有强引用，就不会回收。
真正有效的复用，是**在同一个作用域内重复 Stop/Reset**；跨请求、跨 goroutine 的“长期持有 Timer 实例”反而更容易出问题。
- 局部变量 + 显式
defer timer.Stop()是最安全的模式（适用于单次延迟场景） - 如果必须跨函数传递，确保接收方明确知道该 Timer 已被 Stop，且不再被 Reset
- 用
pprof查runtime.timer对象数量，能快速定位 Timer 泄漏
复杂点在于：Timer 的语义是“一次性”的，所有“复用”本质上都是对这个事实的绕行。理解它为何设计成这样，比记住怎么绕更重要。
