BackgroundWorker 不能直接调用 DoWork，因其是事件而非普通方法；必须通过 RunWorkerAsync() 触发，DoWork 在后台线程执行，禁止访问 UI 控件，传参靠 argument、返回靠 e.Result，更新 UI 须用 ReportProgress/ProgressChanged 或 RunWorkerCompleted。
BackgroundWorker 为什么不能直接调用 DoWork？
因为 DoWork 是事件处理方法，不是普通函数——它由 RunWorkerAsync() 触发并在后台线程执行。手动调用 worker.DoWork(...) 不仅无效，还会在 UI 线程上同步执行，完全失去“不卡界面”的意义。
正确流程是：绑定事件 → 调用 RunWorkerAsync() → 在 DoWork 里写耗时逻辑 → 用 ReportProgress() 和 ProgressChanged 更新进度 → 最终在 RunWorkerCompleted 中处理结果或异常。
-
DoWork内禁止访问 UI 控件（如label.Text），会抛出InvalidOperationException - 传参只能通过
RunWorkerAsync(object argument)的argument参数，对应e.Argument - 返回值必须塞进
e.Result，供RunWorkerCompleted中的e.Result读取
如何安全更新 UI 控件（比如进度条、文本框）？
UI 控件只能在创建它的线程（通常是主线程）访问。BackgroundWorker 提供了两个线程安全的出口：ReportProgress() 触发 ProgressChanged，RunWorkerAsync() 结束后触发 RunWorkerCompleted——这两个事件都在 UI 线程执行。
别试图在 DoWork 里用 Control.Invoke 或 Dispatcher.BeginInvoke，既绕远又易错。
- 需要实时反馈（如下载进度）：在
DoWork中调用worker.ReportProgress(percent, userState)，然后在ProgressChanged里更新progressBar.Value或label.Text - 需要显示最终结果（如计算完成、文件路径）：赋值给
e.Result，在RunWorkerCompleted中取e.Result并更新控件 - 若需传递复杂状态，用
userState参数（类型为object），但注意它不跨线程自动序列化，只是原样透传
常见崩溃场景：取消操作没处理好
BackgroundWorker 的取消机制是协作式的，不是强制终止线程。如果没主动检查 e.Cancel 或 worker.CancellationPending，即使点了“取消”，DoWork 仍会跑完，RunWorkerCompleted 中的 e.Cancelled 也永远是 false。
尤其当循环中调用 Thread.Sleep 或等待 I/O 时，不加检查会导致取消延迟甚至失效。
- 必须在
DoWork的关键位置（如循环开头）检查if (worker.CancellationPending) { e.Cancel = true; return; } -
e.Cancel = true是通知框架“我已响应取消”，否则RunWorkerCompleted中e.Cancelled仍为false - 长时间阻塞调用（如
File.Copy）无法被中断，应改用支持取消的 API（如CopyToAsync+CancellationToken），这时BackgroundWorker就不太适合了
比 BackgroundWorker 更现代的替代方案有哪些？
.NET 4.5+ 推荐用 async/await + Task.Run 替代 BackgroundWorker，代码更扁平、取消更自然、异常传播更直观。
BackgroundWorker 是 WinForms 时代的产物，设计目标是简化 UI 线程交互，但它把异步、进度、取消、错误全耦合在同一个类里，扩展性差，也不支持 await。
- 简单后台任务：用
Task.Run(() => HeavyWork()).ContinueWith(..., TaskScheduler.FromCurrentSynchronizationContext()) - 带进度和取消：用
Progress<T>和CancellationToken配合Task.Run，比ReportProgress类型安全且无 boxing - WinForms 中更新控件：
await后的代码默认回到 UI 线程，无需额外调度 - 如果项目还在维护旧代码，
BackgroundWorker仍可用，但新功能别再基于它设计
真正容易被忽略的是：BackgroundWorker 的 IsBusy 属性只反映是否正在执行 DoWork，它不感知取消过程中的等待、也不反映 RunWorkerCompleted 是否已触发——很多“重复点击导致异常”的问题，根源就在这里。
