timer.stop() 返回 false 仅表示定时器已触发或已被停止，并非失败；正确做法是先 stop() 再立即从 t.c 读一次（用 select + default 避免阻塞），确认无待处理时间后才 reset()。
Timer.Stop() 返回 false 时到底发生了什么
它只说明 Timer 已触发或已手动 Stop() 过，不是“失败”。很多人误以为返回 false 就该重试或 panic，其实不用——只要没触发，Stop() 就安全；一旦触发，再调 Stop() 必然返回 false，这完全正常。
常见错误现象：if !t.Stop() { t.Reset(...) 这种写法会漏掉刚触发但还没来得及读 t.C 的情况，导致重复执行逻辑。
- 正确做法是：先尝试
Stop()，无论真假，都立刻从t.C读一次（带select超时或用select+default避免阻塞） - 只有确认通道里没有待处理的
Time值，才考虑Reset() -
Stop()不会关闭通道，也不会清空已发送但未接收的值
Reset() 不是 Stop() + NewTimer() 的等价替代
Reset() 内部会先尝试 Stop()，再设置新时间，但它不回收旧的底层资源。反复 Reset() 同一个 Timer 是安全的，但前提是：你没在其他 goroutine 里还盯着它的 C 通道。
使用场景：轮询、心跳、状态检查这类需要周期性调整下次触发点的逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 如果 Timer 已触发且你没及时读
t.C，Reset()仍会成功，但上次触发的Time会滞留在通道中，下一次读<t.c></t.c>会立刻拿到那个“过期”的时间 - Go 1.15+ 中
Reset()不再要求必须先Stop()，但老版本（如 1.14）若对已触发的 timer 直接Reset()，行为未定义 - 不要用
Reset()模拟一次性定时器的“重启”——它本就不是为这个设计的
并发读写 timer.C 的典型崩溃
直接在多个 goroutine 里无保护地读 t.C，或者一边 Reset() 一边 range channel，大概率触发 panic: send on closed channel 或静默丢事件。
根本原因：Timer 的底层 channel 在 Stop() 后不会关闭，但 Reset() 也不保证复用原 channel；实际运行中 runtime 可能替换内部 channel，而旧 channel 最终被 GC 关闭。
- 永远只在一个 goroutine 里读
t.C，比如用for range t.C+ 外层控制循环退出 - 若需多处响应超时，用
select等待t.C，而不是起多个 goroutine 同时读 - 别对
t.C做close()、len()或类型断言——它只是个只读
替代方案：用 Ticker + 手动计数比乱 Reset Timer 更稳
如果你其实想要“每 N 秒做一次事，但中间可能暂停/跳过/改间隔”，硬套 Timer 容易绕进状态判断泥潭。这时候 Ticker 加外部控制变量反而更清晰。
性能影响：Ticker 底层也是基于 timer 实现，但它的 channel 是持续复用的，没有 Reset() 引发的潜在 channel 替换问题。
- 暂停：设标志位 +
select忽略ticker.C - 改间隔：停掉旧
Ticker，新建一个（注意旧C通道要读完或用Stop()+select清空） - 单次延迟执行？还是用
Timer，但严格遵循“Stop → 清通道 → Reset”三步，别省中间那步
最常被忽略的一点：Timer 的 C 通道是无缓冲的，它只存一个值。哪怕你 Reset() 十次，只要没读，最后一次的触发时间才会留下；前面九次全丢。这点和直觉相反，但正是很多“定时不准”的根源。
