<p>正确创建并等待单次延时应使用 time.NewTimer(2 * time.Second) 获取 timer，然后 <-timer.C 接收触发信号，最后调用 timer.Stop() 防止资源泄漏。</p>
Go 里 time.Timer 不是“延时几秒后执行一次”就完事的——它默认只触发一次，且一旦触发或被停止，底层资源不会自动回收；用错容易泄漏 goroutine 或 panic。
怎么正确创建并等待一个单次延时？
最常见需求：等 2 秒再干活。别直接 time.Sleep()（阻塞当前 goroutine），要用 time.Timer 配合 。
-
timer := time.NewTimer(2 * time.Second)创建后立即开始计时 - 必须用
阻塞等待通道关闭，不能读 <code>timer.C多次（第二次会阻塞） - 用完记得
timer.Stop()——哪怕已经触发了，也能避免潜在的内存引用残留
为什么 timer.Reset() 后要先 Stop()？
重复使用同一个 time.Timer 是常见优化手段，但 Reset() 不是万能安全操作：
- 如果 timer 已触发（
timer.C已关闭），Reset()会成功，但旧的 goroutine 可能还在往已关闭通道发值 → panic: send on closed channel - 如果 timer 还没触发但已被
Stop()，Reset()才真正生效；否则行为未定义 - 安全写法永远是：
if !timer.Stop() { ，再 <code>timer.Reset(...)
time.AfterFunc() 和 time.Timer 选哪个？
纯“到点执行一个函数”，优先用 time.AfterFunc()：
立即学习“go语言免费学习笔记（深入）”；
- 它内部封装了
time.Timer，自动处理触发和清理，不暴露通道，无误用风险 - 不需要手动
Stop()，也不用担心Reset()时机 - 但无法获取触发时间、不能取消后重设、也不能像
Timer那样参与select多路复用 - 需要参与
select或动态控制生命周期时，才必须用time.Timer
真正难的不是怎么启动一个 timer，而是它在 long-running 服务里被反复 Reset() 时，没人检查 Stop() 返回值，也没人清空已触发的 C 缓冲 —— 这类 bug 往往压测才暴露，且难以复现。
