c#如何使用Timer定时器_c#Timer定时器的几种常见方法

选错 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 导致的“界面卡顿”更加隐蔽，也更难调试。因此，在回调内部进行完善的异常处理，不是最佳实践，而是必须遵守的生存法则。