选错 Timer 类型是 C# 定时任务出问题的最常见原因
在 C# 中实现定时任务，代码本身可能没错，但问题往往出在第一步：用错了 Timer 类。这就像用螺丝刀去敲钉子，工具不对，活儿自然干不好。比如，在控制台程序里误用 System.Windows.Forms.Timer，定时器压根不会触发；反过来，在 UI 线程里用 System.Threading.Timer 直接更新控件，等待你的就是一个跨线程异常；如果想用 await 等待定时任务，却选了老式的同步回调模型，主线程被阻塞也就不奇怪了。
说到底，C# 提供了多种 Timer，各有其明确的适用场景。选对类型，问题就解决了一半。
System.Threading.Timer：后台任务、无 UI 场景的首选
这是最轻量级的选手，纯粹基于线程池执行回调，不依赖任何 UI 框架。因此，它是控制台应用、后台服务或 Worker Service 的理想选择。不过，它的回调执行在非 UI 线程上，这意味着你不能直接在其中操作像 TextBox.Text 这样的控件。
- 构造与异常处理：构造时需要传入一个
TimerCallback委托。这里有个关键细节：务必在委托内部捕获并处理异常。否则，一旦回调抛出未捕获的异常，定时器就会“静默”停止工作，不报错也不继续执行，排查起来相当棘手。var timer = new Timer(_ => { try { DoWork(); } catch (Exception ex) { Console.WriteLine($"Error: {ex}"); } }, null, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(5)); - 动态调整：通过
Change()方法可以动态改变触发间隔。需要注意的是，第一个参数dueTime指的是下一次触发距离现在的延迟时间，而不是一个绝对的起始偏移量。将其设为TimeSpan.Zero则表示立即触发下一次。 - 资源释放：必须手动调用
Dispose()来释放其占用的线程池资源。推荐使用using语句块或在适当生命周期内显式释放，以避免资源泄漏。
System.Timers.Timer：需要事件模型 + 自动重置的后台服务
这个类可以看作是 System.Threading.Timer 的一个封装，提供了更清晰的 Elapsed 事件模型，并且支持 AutoReset（自动重置）和 Enabled 等属性，语义上更直观。但本质上，它的回调仍然在线程池线程上触发。
- UI 线程访问：在
Elapsed事件处理器中，同样不能直接访问 WinForms 或 WPF 的控件。更新 UI 必须通过Control.Invoke或Dispatcher.Invoke进行封送。 - 间隔设置：其
Interval属性单位是毫秒（double类型），而不是TimeSpan。将其设置为 0 是无效的，通常最小有效值为 1。 - 停止与销毁：调用
Stop()方法和设置Enabled = false效果相同，但前者意图更明确。一旦调用了Dispose()，这个定时器实例就不能再调用Start()了。
System.Windows.Forms.Timer：WinForms UI 更新唯一安全的选择
这是为 WinForms 量身定制的定时器。它的 Tick 事件严格在创建它的 UI 线程上触发，因此所有控件操作都是天然线程安全的。不过，它的精度较低，实际间隔可能比设定值多出 10 到 30 毫秒，并且仅适用于 WinForms 应用程序。
- 使用限制：它必须在窗体线程的上下文中创建和使用。在控制台程序或 WPF 应用中实例化它，它是不会工作的。
- 间隔的合理设置：
Interval单位也是毫秒。设置过小的值（比如 1 毫秒）没有意义，因为系统的消息泵处理不过来。 - 避免耗时操作：切勿在
Tick事件处理器中执行耗时操作，否则会导致 UI 界面卡顿。如果确实需要执行异步任务，应该在Task.Run中启动，并在任务完成后通过Invoke回到 UI 线程更新界面。
.NET 6+ 推荐：PeriodicTimer 配合 await
如果你的项目基于 .NET 6 或更高版本，并且定时任务逻辑本身是支持异步的（例如发起 HTTP 请求、读写文件），那么 PeriodicTimer 是目前最简洁、最现代的方案。它不绑定任何特定线程，也不强制使用回调，而是设计为与 await foreach 配合使用。
- 定位与替代：它并非用来直接替代旧的 Timer 类型，而是专门为 async/await 异步流场景设计的。不能用它直接替换同步的回调逻辑。
- 使用模式：必须搭配
async方法和IAsyncEnumerable模式来使用：var timer = new PeriodicTimer(TimeSpan.FromSeconds(2)); while (await timer.WaitForNextTickAsync()) { await DoWorkAsync(); // 这里可以安全地使用 await } - 间隔调整：它没有提供
Change()方法。如果需要改变触发间隔，只能将现有实例释放（Dispose），然后重新创建一个新的PeriodicTimer。
最后，有一个容易被忽略但至关重要的点：所有基于线程池的 Timer（包括 System.Threading.Timer 和 System.Timers.Timer）在回调中如果发生未捕获的异常，整个定时器就会停摆。它不会自动重试，也不会将错误抛到控制台，只会静默终止。这种“故障静默”的特性，比 UI Timer 导致的“界面卡顿”更加隐蔽，也更难调试。因此，在回调内部进行完善的异常处理，不是最佳实践，而是必须遵守的生存法则。
