WinForms/WPF UI控件非线程安全，子线程直接改Text会抛InvalidOperationException；必须用Invoke/BeginInvoke（WinForms）或Dispatcher.Invoke/BeginInvoke（WPF）切回UI线程。
为什么直接在子线程改 TextBox.Text 会报错
因为 winforms 和 wpf 的 ui 控件不是线程安全的，control.invokerequired 返回 true 时硬写 text = "xxx"，会触发 invalidoperationexception: “线程间操作无效”。这不是“不允许”，而是底层没做同步保护——控件内部状态（比如句柄、绘图上下文）只归属创建它的线程。
常见错误现象：NullReferenceException 看似和线程无关，其实是子线程里访问了尚未完成初始化的控件引用；或者界面突然不响应，但没报错，那是死锁在 Invoke 等待主线程空闲。
- WinForms 下必须用
Control.Invoke或Control.BeginInvoke跳回 UI 线程执行赋值 - WPF 下对应的是
Dispatcher.Invoke或Dispatcher.BeginInvoke - 别用
Application.DoEvents()模拟“让出控制权”——它不解决线程安全，反而可能引发重入或状态混乱
BeginInvoke 和 Invoke 到底该选哪个
Invoke 是同步调用：子线程会卡住，等 UI 线程执行完委托才继续；BeginInvoke 是异步的，发完就走，不等结果。选哪个取决于你是否依赖更新后的副作用（比如改完 Label.Text 后立刻读取 Label.Width 计算布局）。
使用场景举例：后台解析 JSON 后要刷新列表，只需显示新数据 → 用 BeginInvoke；上传文件后要根据 UI 控件当前 Enabled 状态决定是否弹窗 → 必须用 Invoke，否则读到的是旧值。
-
BeginInvoke更轻量，适合纯展示类更新，避免子线程阻塞 -
Invoke在高频率调用时容易堆积消息队列，导致 UI 延迟感变强 - .NET 6+ WinForms 中
Control.Invoke内部已优化为尽量不跨线程切换，但语义不变，仍需按规则调用
WPF 里用 Binding 替代手动更新更稳吗
是的，但有个关键前提：绑定源（ViewModel）得实现 INotifyPropertyChanged，且属性变更通知必须从 UI 线程发出。如果后台线程直接改 ViewModel 属性，即使有 NotifyPropertyChanged，UI 也不会刷新——WPF 的 Binding 监听器默认只响应 UI 线程的事件。
性能影响明显：高频更新（如传感器每 50ms 推一个值）用 Binding + INotifyPropertyChanged 比反复 Dispatcher.Invoke 开销小，因为 Binding 引擎做了合并和节流；但首次绑定耗时略高，且调试时容易漏掉 OnPropertyChanged 调用。
- 推荐模式：子线程处理数据 → 封装成新对象 → 用
Dispatcher.Invoke替换整个ObservableCollection项，而不是逐个改属性 - 别在
get访问器里触发耗时操作（比如查数据库），这会让 Binding 在 UI 线程上卡住 -
Binding.UpdateSourceTrigger=PropertyChanged对性能无实质帮助，只是改变触发时机，不能绕过线程限制
Task.Run 里更新 UI 为什么还是崩
因为 Task.Run 默认在 ThreadPool 线程执行，它和 UI 线程仍是隔离的。await Task.Run(...) 只保证 await 后面的代码回到原始上下文（比如 UI 线程），但 Task.Run 内部的代码本身就在子线程——很多人误以为 await 能“自动”把里面的赋值带进 UI 线程。
典型错误写法：await Task.Run(() => { label.Text = "done"; }); —— 这行依然在子线程执行，照样崩。
- 正确做法：在
Task.Run外部 await，然后在 await 后（即 UI 线程）更新控件 - 或者用
Progress：构造var progress = new Progress，再在(s => label.Text = s); Task.Run里调progress.Report("xxx")，它内部自动封送到 UI 线程 - 别对
async void方法做 UI 更新，异常会直接崩溃进程，且无法被 try/catch 捕获
事情说清了就结束。最常被忽略的是：哪怕用了 BeginInvoke，如果传入的委托里又开了新线程（比如调了另一个 Task.Run），那个嵌套层依然不安全。线程边界是一层一层的，不是设个开关就全局生效。
