应根据运行环境选择Timer：WinForms用System.Windows.Forms.Timer，WPF用DispatcherTimer，后台场景用System.Threading.Timer或PeriodicTimer（.NET 6+），并注意线程安全、异常捕获与正确释放。
Timer 在 C# 里到底该用哪个？
别直接写 System.Threading.Timer 或 System.Windows.Forms.Timer，先看线程上下文——你在 WinForms、WPF、ASP.NET Core 还是控制台程序里跑？不同场景下，Timer 不仅行为不同，出问题时连错误都藏得不一样。
最常踩的坑是：在 WinForms 里误用 System.Threading.Timer 更新 UI 控件，结果抛出 InvalidOperationException: Cross-thread operation not valid；或者在 ASP.NET Core 后台服务里用了 System.Windows.Forms.Timer，部署就直接失败（因为没窗体消息循环）。
- WinForms/WPF 界面更新 → 用
System.Windows.Forms.Timer（WinForms）或DispatcherTimer（WPF） - 后台计算、IO、无 UI 场景 → 用
System.Threading.Timer或System.Timers.Timer - 托管服务（如 ASP.NET Core Hosted Service）→ 优先用
System.Threading.Timer，或更现代的IHostedService+PeriodicTimer（.NET 6+）
System.Threading.Timer 怎么避免“只触发一次”？
它默认不自动重复，很多人调了 new Timer(callback, state, dueTime, period) 却发现只执行了一次，其实是把 period 设成了 Timeout.Infinite 或 0，或者 callback 里抛了未捕获异常导致后续调度被静默终止。
System.Threading.Timer 的回调运行在线程池线程上，异常不会冒泡到主线程，也不会停掉定时器——但下次触发前如果 callback 崩了，那这次调度就丢了，看起来像“断掉”。
- 确保
period > 0（比如TimeSpan.FromSeconds(5)），dueTime和period都用毫秒或TimeSpan，别混用 int 和 long - callback 必须自行 try/catch，否则异常会吞掉，定时器继续跑但什么也不做
- 不要在 callback 里直接操作 UI 控件；需要更新界面时，走
Control.Invoke或Dispatcher.Invoke
var timer = new Timer(_ => {
try {
Console.WriteLine("Tick at " + DateTime.Now);
// 可能出错的操作
DoWork();
} catch (Exception ex) {
// 必须捕获，否则你看不到错误，timer 也看似“卡住”
Console.WriteLine($"Error: {ex.Message}");
}
}, null, TimeSpan.Zero, TimeSpan.FromSeconds(3));PeriodicTimer 是不是比老 Timer 更好用？
是，但只限 .NET 6+。它专为 async 场景设计，支持 await，且取消语义清晰，没有“回调线程不可控”的问题。但它不能替代所有场景——比如你仍需在 WinForms 中安全刷新 Label，PeriodicTimer 自身不提供 UI 线程调度能力。
它的核心优势是：基于 CancellationToken，可与 async/await 自然融合，且每次 tick 都等上一次完全结束才开始下一轮（不像 System.Threading.Timer 可能并发触发）。
- 必须配合
await foreach使用，不能当普通 Timer 那样“启动即不管” - 构造后不会自动开始，要显式进入 await 循环；退出循环即停止
- 如果某次 tick 耗时超过间隔，下一次会在它结束后立即触发（无堆积，也不跳过）
var periodicTimer = new PeriodicTimer(TimeSpan.FromSeconds(2));
while (await periodicTimer.WaitForNextTickAsync()) {
await DoWorkAsync(); // 安全 await，不会并发
}为什么 Timer.Stop() 有时没用？
因为 Stop() 只对 System.Timers.Timer 和 System.Windows.Forms.Timer 有效；System.Threading.Timer 根本没有 Stop() 方法——它靠 Dispose() 终止，而且必须确保 Dispose 被调用，否则线程池回调可能还在跑。
另一个常见问题是：在 callback 中调用 timer.Dispose()，但 Dispose 并不阻塞当前执行，后续已入队的 tick 仍可能触发（尤其高频率场景）。真正安全的做法是加状态标记 + 外层检查。
-
System.Threading.Timer：用timer?.Dispose()，并确保引用置 null；若需中途退出 callback，用闭包变量控制 -
System.Timers.Timer：调Stop()后最好也Dispose()，避免事件订阅泄漏 - 所有 Timer，只要涉及资源（文件、DB 连接、HttpClient），务必在 callback 内做好异常防护和资源释放
Timer 的复杂点不在启动，而在生命周期管理与异常边界。多数故障不是“设不起来”，而是“停不干净”或“崩了不知道”。特别是跨线程、异步等待、服务长期运行这些组合场景，稍不注意，timer 就变成内存泄漏或幽灵任务的温床。
