BackgroundWorker 的 DoWork 不能直接操作 UI 控件，必须通过 ProgressChanged 或 RunWorkerCompleted 更新；取消需手动检查 CancellationPending 并设 e.Cancel = true；参数与结果仅通过 e.Argument 和 e.Result 传递；WorkerReportsProgress 和 WorkerSupportsCancellation 必须显式启用。
DoWork 里不能直接操作 UI 控件，这是铁律
很多人一上手就写 textBox1.Text = "loading..." 在 DoWork 事件里，结果直接抛 InvalidOperationException: 跨线程操作无效。BackgroundWorker 的 DoWork 是在后台线程跑的，而 WinForms 控件只认创建它的那个 UI 线程。
- 所有 UI 更新（改
Label.Text、设ProgressBar.Value、启用/禁用按钮）必须放在ProgressChanged或RunWorkerCompleted里 -
ProgressChanged和RunWorkerCompleted是 BackgroundWorker 自动封送（marshal）到 UI 线程的，安全 - 想传数据过去？用
e.UserState（任意对象）或e.ProgressPercentage（整数），别试图从DoWork直接抓控件引用
取消不是“按一下就停”，而是你得主动配合
CancelAsync() 只是给 CancellationPending 打个标记，它不会中断正在执行的代码——尤其是 Thread.Sleep()、File.ReadAllBytes() 或数据库查询这类阻塞调用。
- 必须在
DoWork的循环体里定期检查bw.CancellationPending - 一旦为
true，立刻设e.Cancel = true并return，否则用户点取消等于白点 - 阻塞 IO 操作要换支持
CancellationToken的 API，比如用HttpClient.GetAsync(uri, token)替代老式同步请求 - 不设
e.Cancel = true，RunWorkerCompleted里就分不清是“正常完成”还是“被取消”
传参和返回值只走 e.Argument 和 e.Result
BackgroundWorker 不支持多参数、泛型或 await，它只认一个入口、一个出口：全部靠 object 类型的管道。
- 启动时传参只能用
RunWorkerAsync(obj)，接收端强制转型：int max = (int)e.Argument，记得判空和异常捕获 - 返回结果只能赋给
e.Result，比如e.Result = new { Success = true, Count = 42 }，取的时候也要手动转型或用as - 别指望在
DoWork里 throw 异常来通知 UI —— 它会被吞进e.Error，不检查就静默失败 - 没有
async/await支持，真要异步 IO，得自己用Task.Run(() => {...})包一层再等，但那就偏离 BackgroundWorker 设计本意了
WorkerReportsProgress 和 WorkerSupportsCancellation 必须显式开启
这两个布尔属性默认都是 false，不开就等于没装油门和刹车——调 ReportProgress() 会炸出 InvalidOperationException，调 CancelAsync() 则完全没反应。
- 初始化阶段就得设死：
bgWorker.WorkerReportsProgress = true;、bgWorker.WorkerSupportsCancellation = true; - 顺序无关紧要，但必须在
RunWorkerAsync()之前设置，否则无效 - 检查
IsBusy再调RunWorkerAsync()是基本防重入手段，避免用户狂点“开始”导致状态混乱
DoWork、把进度/结果推到 UI 线程、靠 CancellationPending 配合退出。它不复杂，但每个环节都要求你明确知道“谁在线程上、谁在管什么”，漏掉任一环，程序就表现得像卡死或不响应。 
