timer.After 不能用于循环重置定时任务，因其返回单次通道、读完即关闭；应改用 time.NewTicker 或 time.NewTimer 配合 Reset。
为什么 timer.After 不能直接用于循环重置定时任务
很多人想用 timer.After 实现“每 N 秒执行一次”，结果发现逻辑只跑了一次就停了。这是因为 timer.After 返回的是单次 <time.time></time.time> 的 chan，读完一次就关闭，无法复用。
正确做法是用 time.NewTimer 配合 Reset()，或更常见的——直接用 time.Ticker。
-
time.After(d)：适合「延迟一次」，比如超时控制、延后启动 -
time.NewTimer(d)：适合「延迟一次 + 可手动重置」，比如带取消逻辑的单次任务 -
time.NewTicker(d)：适合「周期性触发」，底层复用同一个定时器，比反复 new Timer 更轻量
在 goroutine 中使用 Ticker 必须显式 stop
不调用 ticker.Stop() 会导致 goroutine 和底层 ticker 持续运行，即使外层逻辑已退出。Go runtime 不会自动回收活跃的 time.Ticker，它会一直向 ticker.C 发送时间点，造成 goroutine 泄漏和内存缓慢增长。
典型错误写法：
立即学习“go语言免费学习笔记（深入）”；
go func() {
ticker := time.NewTicker(5 * time.Second)
for range ticker.C {
doWork()
}
}()正确写法（带退出控制）：
done := make(chan struct{})
go func() {
defer close(done)
ticker := time.NewTicker(5 * time.Second)
defer ticker.Stop() // 关键：确保退出前释放资源
for {
select {
case <-ticker.C:
doWork()
case <-done:
return
}
}
}()并发场景下 Ticker 与 channel select 的配合要点
多个定时器或混合 I/O 事件时，select 是标准解法，但要注意几个易错点：
- 如果
ticker.C和其它 channel 同时就绪，select是伪随机选择，不能依赖顺序 - 不要在
case 分支里做耗时操作，否则会拖慢下一次 tick —— <code>Ticker不跳过未消费的 tick，而是累积在 channel 缓冲区（默认缓冲 1），若持续阻塞，可能引发堆积或 panic（当缓冲满且无 receiver） - 如需严格节拍（如心跳、采样），应把耗时逻辑扔进新 goroutine，或用带缓冲的 channel 解耦
例如安全的节拍处理：
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
for {
select {
case <-ticker.C:
go doWork() // 避免阻塞 ticker
case <-quit:
return
}
}Timer.Reset 和 Ticker.Reset 的行为差异
两者都支持 Reset(d)，但语义不同：
-
Timer.Reset(d)：停止当前计时，重新以d开始倒计时；若原 timer 已触发，Reset仍有效；若原 timer 未触发但已Stop()，Reset会重新激活它 -
Ticker.Reset(d)：立即停止当前 ticker，并以新间隔d创建一个全新 ticker；旧的ticker.Cchannel 不再有值，必须用新的 channel（但通常没人这么干，因为Reset对 ticker 很少必要）
所以实际中：Timer.Reset 常见于动态超时调整；Ticker.Reset 几乎不用，改用 Stop() + NewTicker() 更清晰。
真正容易被忽略的是：所有 Reset 调用前，必须确保原 timer/ticker 没有处于已触发但尚未读取的状态，否则可能 panic 或行为异常 —— 尤其在多 goroutine 并发调用 Reset 时，务必加锁或通过 channel 协作。
