Timer与Task.Run混用易丢任务，因Timer回调在线程池线程执行且不感知异步上下文，await后续代码可能在Timer被释放后执行；应避免在回调中直接await，改用Task.Run启动后台任务或同步等待。
Timer 和 Task.Run 混用会丢任务
很多人一上来就用 System.Threading.Timer，在回调里直接调用耗时方法或 await 异步操作，结果发现定时不准、任务莫名消失、甚至抛出 ObjectDisposedException。根本原因是 Timer 回调运行在线程池线程上，且不感知异步上下文——await 之后的代码可能在另一个线程执行，而 Timer 已经被 GC 或手动释放。
- 别在
Timer回调里写await DoSomethingAsync()；真要异步，必须用Task.Run(() => DoSomethingAsync()).Wait()同步等待（仅适用于短任务） - 更稳妥的做法：回调中只触发
Task.Run启动后台任务，自己不等，也不管它成败（需自行加日志和异常捕获） - 如果方法本身是同步的（比如发个 HTTP 请求用
HttpClient.Send()），直接调用没问题；但注意别让单次执行时间超过 Timer 间隔，否则会堆积
System.Timers.Timer 的 AutoReset = false 容易被忽略
System.Timers.Timer 看起来更“高级”，有 Elapsed 事件，但它默认开启 AutoReset = true。这意味着只要没停，它会不断触发，哪怕上一次还没执行完。你可能以为“每 5 秒跑一次”，实际变成了“只要上次执行完就立刻再跑”，尤其在调试时卡住几秒，松开后瞬间连跑好几次。
- 想严格按固定间隔执行（不管上次是否完成），保持
AutoReset = true，但务必在方法入口加锁或用Interlocked控制并发 - 想确保“上一次彻底结束，才开始下一次”，设
AutoReset = false，并在事件处理末尾手动调用timer.Start() - 别忘了
timer.Enabled = true和timer.Start()不是等价的——前者会重置已过期的计时，后者不会；生产环境建议统一用Start()/Stop()
Windows Forms 里用 Timer 控件反而最省心
如果你在 WinForms 应用里只是刷新 UI（比如更新 Label 时间、轮询状态），别碰线程池 Timer。用设计器拖出来的 System.Windows.Forms.Timer 就够了——它的 Tick 事件天然在 UI 线程触发，不用 Invoke，也不会跨线程异常。
- 它不支持毫秒级精度（实际最小约 15ms），但对 UI 刷新完全够用
- 生命周期绑定窗体：窗体关闭时它自动停止，不会引发内存泄漏
- 别把它和
System.Threading.Timer混用——同一个项目里两种 Timer 共存时，容易误调Dispose()导致一个失效
取消定时任务时，Dispose 和 Stop 不是一回事
很多人调了 timer.Stop() 就以为万事大吉，结果发现内存没释放、GC 不回收，甚至程序退出前还在偷偷触发最后一次回调。这是因为 Stop() 只暂停计时，对象还活着；真正释放资源得靠 Dispose()。
-
System.Threading.Timer必须显式调用Dispose()；它没有Stop()方法 -
System.Timers.Timer调Stop()后仍需Dispose()，否则底层SafeHandle会泄漏 - 推荐用
using块包裹（仅限System.Threading.Timer），或在IDisposable类型中统一管理；WinForms 的Timer可以只Stop()，窗体销毁时自动清理
事情说清了就结束。Timer 的坑不在语法，而在它和线程、生命周期、异步模型的咬合点——这些地方稍微偏一点，问题就藏得深。
