WinForms控件非线程安全，必须由创建线程访问；跨线程操作会引发InvalidOperationException；应使用Invoke（同步）或BeginInvoke（异步）封送至UI线程，并检查IsHandleCreated和IsDisposed避免异常。
为什么子线程直接改 TextBox.Text 会报“线程间操作无效”
因为 WinForms 控件不是线程安全的，所有 UI 元素必须由创建它的线程（通常是主线程/UI 线程）访问。子线程一碰 Label.Text 或 ListBox.Items.Add，立刻抛出 InvalidOperationException：“线程间操作无效：不是创建控件的线程在对其进行访问”。
这不是 .NET 故意设障，而是 Windows 消息循环机制决定的——UI 控件底层依赖 HWND 和消息泵，跨线程调用会破坏消息顺序和句柄状态。
- 即使看起来“偶尔能跑通”，也是未触发竞态的侥幸，不能当正常行为
-
Control.CheckForIllegalCrossThreadCalls = false是禁用检查，不是解决问题，上线后大概率崩溃或界面卡死 - WPF 用的是
Dispatcher.Invoke，逻辑类似但 API 不同，别混用
Invoke 和 BeginInvoke 怎么选
两者都把委托封送到 UI 线程执行，区别在于是否等待执行完成：
-
Invoke：同步调用，子线程会阻塞，直到 UI 线程执行完委托才继续。适合需要立刻拿到返回值、或后续逻辑强依赖 UI 更新结果的场景（比如更新进度条后立即读取ProgressBar.Value） -
BeginInvoke：异步调用，子线程不等，发完就走。UI 更新可能延迟几毫秒，但不会卡住工作线程。绝大多数日志刷新、状态提示、列表追加都该用它 - 如果控件已被释放（比如窗体已关闭），
Invoke可能抛ObjectDisposedException；BeginInvoke则静默失败——这点常被忽略，建议加if (IsHandleCreated)判断
示例：
if (this.InvokeRequired)
{
this.BeginInvoke(new Action(() => label1.Text = "已完成"));
}
else
{
label1.Text = "已完成";
}
Lambda 捕获变量导致的常见内存泄漏
写 this.BeginInvoke(() => textBox1.Text = result) 看似简洁，但闭包会隐式捕获 this 和 textBox1，如果子线程长期运行（比如后台轮询），而窗体已关闭，这些委托还在排队，就会让窗体对象无法被 GC 回收。
- 避免在 lambda 中直接引用控件实例，改用字符串、数字等值类型参数传入
- 更稳妥的做法是显式检查生命周期：
if (IsHandleCreated && !IsDisposed) { BeginInvoke(new MethodInvoker(() => UpdateStatus("成功"))); } - 如果用了
async/await+Task.Run，别在await后直接操作控件——await返回的上下文不保证是 UI 线程，仍需Invoke
替代方案：用 BackgroundWorker 还是 async/await
BackgroundWorker 自带 ProgressChanged 和 RunWorkerCompleted 事件，天然在 UI 线程触发，省去手动 Invoke。但它已标记为“过时”，且不支持 async 方法体。
- 新项目优先用
async/await：把耗时操作包进Task.Run，然后await完再用Invoke更新 UI - 但注意：不要在
await后直接写label.Text = ...，除非你确认当前SynchronizationContext是 WinForms 的（通常成立），否则加一层if (InvokeRequired) Invoke(...)更稳 -
Task.Run里别调await第三方异步方法后再Invoke——这等于把线程切换交给了别人，控制权变弱
事情说清了就结束。
