system.timers.timer 和 system.threading.timer 均在后台线程触发，直接更新 winforms 控件会抛出跨线程异常；前者可通过 synchronizingobject = this 自动封送至 ui 线程，后者须手动 invoke；threading.timer 内存开销极低（约 0 b），timers.timer 约 18 kb，且首次触发延迟更稳定。
System.Timers.Timer 和 System.Threading.Timer 都不能直接更新 WinForms 控件，但处理方式和适用场景完全不同——选错会导致 UI 崩溃、内存泄漏或定时失准。
System.Timers.Timer.Elapsed 为什么一调用就报跨线程异常
默认情况下，Elapsed 事件在**线程池线程**上触发，而 WinForms 控件（如 label1.Text）只能由创建它的 UI 线程访问。不加防护就赋值会立刻抛出 InvalidOperationException: "Cross-thread operation not valid"。
- 最简单修复：设置
SynchronizingObject = this（仅限 WinForms 窗体实例），让事件自动封送到 UI 线程 - 若在非窗体类（如服务类、ViewModel）中使用，
SynchronizingObject不可用，必须手动this.Invoke(...) -
AutoReset = false时需在事件内显式调用Start()，否则只触发一次 - 注意重入风险：若
Elapsed处理耗时 >Interval，可能多个线程并发进入——加锁或用Interlocked控制状态
System.Threading.Timer 回调里访问 this.Label 报错的根本原因
System.Threading.Timer 的回调函数（TimerCallback）完全脱离 UI 上下文，它甚至不知道窗体是否存在。闭包捕获 this 后，只要回调委托还活着，窗体就无法被 GC 回收——这是隐蔽的内存泄漏源头。
- 必须在窗体
FormClosed或Dispose中调用timer.Dispose()，否则定时器持续运行 - 更新 UI 必须显式切回主线程：
this.Invoke((MethodInvoker)(() => label1.Text = "ok")) - 不要在回调里直接调用
Thread.Sleep或阻塞 IO，会占用线程池线程，拖慢其他异步操作 - 构造时传入的
state参数若为窗体引用，等同于延长其生命周期——改用弱引用或分离数据模型
为什么 System.Threading.Timer 比 System.Timers.Timer 更省内存
System.Threading.Timer 是 .NET 最底层的定时器实现，无事件模型、无属性封装，纯靠委托回调驱动。实测每个实例内存开销接近 0 字节；而 System.Timers.Timer 内部包装了前者，并额外维护事件订阅列表、同步上下文、AutoReset 状态等，单个实例约占用 18KB。
- 高频率、大量定时器场景（如每秒上千个心跳检测），优先选
System.Threading.Timer -
System.Timers.Timer的Start()/Stop()更符合直觉，适合业务逻辑较重、需频繁启停的组件 - 首次触发延迟：
System.Threading.Timer更稳定（通常 System.Timers.Timer 可能延迟达 90ms - 两者都不依赖消息泵，可安全用于控制台、Windows 服务、ASP.NET Core 后台任务
真正容易被忽略的点是：无论用哪个，只要涉及 UI 更新，就必须明确线程归属——不是“能不能”，而是“谁来负责切线程”。漏掉 Dispose 或 Invoke，问题不会立刻暴露，而是在窗体关闭后悄悄吃内存或崩 UI。
