应选system.threading.timer做后台任务：它最轻量、回调在线程池执行、需手动异常处理和dispose防泄漏；system.timers.timer易丢触发且异常静默；winforms.timer仅限ui刷新。
别用 System.Windows.Forms.Timer 做后台任务，它只能在 UI 线程跑，一卡全卡；真要定时执行耗时操作，得用 System.Threading.Timer 或 System.Timers.Timer，但二者行为差异很大，选错就丢任务、漏触发、线程炸锅。
怎么选对 Timer 类型：看线程模型和自动重置需求
System.Threading.Timer 是最轻量、最可控的选项：回调直接在 ThreadPool 线程上执行，不绑定 UI，也不自动捕获异常（意味着异常会直接终结该次回调，但不影响后续触发）；System.Timers.Timer 内部包装了 Threading.Timer，加了 Elapsed 事件和 AutoReset 控制，但默认会吞掉未处理异常（导致你根本不知道任务崩了），且 Enabled = false 不等于立刻停掉正在执行的回调。
- 要精确控制生命周期、需手动处理异常、任务可能较长 → 选
System.Threading.Timer - 只是简单轮询、希望开箱即用事件模型、能接受异常静默 → 可用
System.Timers.Timer，但必须手动订阅Elapsed并设AutoReset = true -
System.Windows.Forms.Timer只用于 WinForms 界面刷新，比如每秒更新一个Label.Text，绝不能用来发 HTTP 请求或读文件
System.Threading.Timer 的正确初始化和释放
它没有 Start/Stop 方法，靠构造函数和 Change() 控制启停；不调用 Dispose() 会导致计时器一直持有回调委托，GC 清不掉，内存泄漏。常见错误是把 timer 声明为局部变量，方法一退出就丢了引用，但计时器还在后台跑。
- 必须把
Timer实例存为类字段或static变量，确保生命周期可控 - 构造时传入
callback、state、dueTime（首次延迟）、period（间隔），设Timeout.Infinite表示只执行一次 - 停用时调用
timer.Change(Timeout.Infinite, Timeout.Infinite)，再调timer.Dispose()；别只 Dispose，否则可能触发最后一次回调时访问已释放资源 - 回调里别直接更新 UI 控件——它不在 UI 线程，要用
Control.Invoke或SynchronizationContext
private Timer _timer;
private void StartBackgroundCheck()
{
_timer = new Timer(CheckServerStatus, null, TimeSpan.FromSeconds(5), TimeSpan.FromMinutes(1));
}
private void CheckServerStatus(object state)
{
try
{
// 耗时操作：HttpClient.GetAsync...
}
catch (Exception ex)
{
// 必须自己捕获并记录，否则异常被吞掉
Console.WriteLine($"Check failed: {ex.Message}");
}
}
为什么 System.Timers.Timer 的 Elapsed 事件会“丢失”调用
当上一次 Elapsed 回调还没执行完，下一次触发时间到了，System.Timers.Timer 默认会跳过这次触发（不是排队等，是直接丢弃）。这在高负载或任务偶发变慢时非常隐蔽——你以为每分钟执行一次，其实可能连续几分钟没调用。
- 这不是 bug，是设计如此；想避免，得在回调开头加锁（如
Monitor.TryEnter）或设AutoReset = false，手动在回调末尾调Start() - 更关键的是：
Elapsed事件的异常默认被框架吞掉，连AppDomain.UnhandledException都抓不到；必须显式订阅Timer.Elapsed += (s, e) => { /* try/catch */ }并在内部包一层try/catch - 如果用在 Windows Service 或 ASP.NET Core 后台服务中，记得在
OnStop或IHostedService.StopAsync里调timer.Stop()和timer.Dispose()，否则进程退出时计时器还在发请求
真正难的不是启动一个 Timer，而是让它的每次回调都可预期、可监控、可中断。很多人卡在“为什么有时执行有时不执行”，其实问题不在间隔设置，而在回调里没处理好异常、没控制并发、没正确释放句柄。
