在未过期或未停止的Timer上调用Reset()可能引发哪些问题？

违反官方文档中Timer.Reset的调用规范，会引发以下具体问题：

• 旧通道值触发错误逻辑
  要是在Timer没过期、且程序没从t.C取过值的情况下直接调用Reset，原Timer到期后会往t.C塞一个值。这个值会留在通道里，后续代码读t.C时，会把它当成新Timer触发的信号，直接打乱预期逻辑。比如你本来想让新Timer等10秒再执行任务，结果原Timer的3秒到期值还在通道里，Reset后立刻读到这个值，任务被提前执行。

• Reset失效，Timer不按预期工作
  当Timer还在运行（既没停也没过期）就直接调用Reset，哪怕内部会尝试停掉原Timer，也可能因为时序问题出现状态竞争：比如原Timer刚好在调用Reset的瞬间过期，导致新的Timer设置没生效，或者原Timer的触发信号还是会发去通道，让后续逻辑彻底乱套。

• 新Timer触发信号丢失
  Timer.C是缓冲为1的通道。如果Timer过期后没排空通道就调用Reset，通道里的旧值会占满缓冲区。等新Timer到期时，发送时间值的操作会因为通道满而直接丢弃信号，后续代码通过<-t.C等待新触发时，永远收不到信号，任务彻底卡住。

• 并发场景下的不可控行为
  在多goroutine环境里，不规范的Reset会放大状态竞争问题。比如一个goroutine在等着读t.C，另一个goroutine乱调用Reset，可能读到的是原Timer的旧值，或者新Timer的触发信号直接丢了，程序行为完全不可预测，排查起来异常困难。

内容的提问来源于stack exchange，提问作者Lawliet