UI线程卡死是因消息泵停摆，所有输入、渲染、事件均冻结；跨线程改UI必抛InvalidOperationException；WPF用Dispatcher.InvokeAsync，WinForms用Control.Invoke；推荐async/await+ConfigureAwait(false)避免死锁。
UI线程卡死是因为它同时负责消息泵和渲染
WPF 和 WinForms 的 UI 线程不是“普通工作线程”，而是绑定了 Dispatcher（WPF）或 Application.Run 消息循环（WinForms）。所有用户输入、控件重绘、布局计算、事件分发都靠它逐条处理。一旦你在 UI 线程里调用 Thread.Sleep(2000)、File.ReadAllBytes(@"C:/big.log") 或执行未 await 的 Task.Run(...).Result，消息泵就停摆——窗口变灰、鼠标悬停无反馈、右键菜单打不开，不是“慢”，是彻底冻结。
直接在后台线程改 UI 控件会抛 InvalidOperationException
这不是设计缺陷，而是线程安全强制策略。WPF 的 TextBox.Text、WinForms 的 Label.Text 都只允许创建它的线程访问。你用 Task.Run(() => { label1.Text = "done"; })，运行时一定报错：System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it.
- WPF 必须用
Dispatcher.InvokeAsync()或await Dispatcher.InvokeAsync() - WinForms 必须用
Control.Invoke()或Control.BeginInvoke() - 别用
Control.InvokeRequired手动判断——现代写法应默认走异步调度
推荐模式：async/await + ConfigureAwait(false) 避免死锁
典型错误是写了 async void Button_Click，里面调用 var data = await LoadDataAsync().Result;——这会同步阻塞 UI 线程，且 .Result 在有上下文的线程上调用极易死锁。正确路径是全程 async/await，并在非 UI 逻辑中显式脱离上下文。
private async void Button_Click(object sender, RoutedEventArgs e)
{
// ✅ 正确：不阻塞 UI 线程，后台加载，再切回 UI 更新
var data = await LoadDataAsync(); // 内部用了 ConfigureAwait(false)
textBox.Text = data;
}
private async Task LoadDataAsync()
{
// ⚠️ 关键：这里不需 UI 上下文，避免线程争抢
return await File.ReadAllTextAsync("data.txt").ConfigureAwait(false);
}
WinForms 和 WPF 的 UI 调度语法差异要记牢
两者都禁止跨线程访问控件，但 API 名称和默认行为不同。WPF 的 Dispatcher 是延迟调度、可 await；WinForms 的 Invoke 是同步阻塞，BeginInvoke 是异步但不返回 Task，容易误用。
- WPF 更新控件：
await Dispatcher.InvokeAsync(() => label.Content = "ok"); - WinForms 更新控件：
this.Invoke((MethodInvoker)(() => label.Text = "ok")); - WinForms 中避免
BeginInvoke后无法 await —— 它不返回Task，没法链式 await - 如果用了第三方库（如 ReactiveUI），它们内部已封装调度逻辑，无需手动
Invoke
WPF 的 Dispatcher 默认优先级是 Normal，而 WinForms 的 Invoke 总是同步执行——这点在高频更新（比如进度条每 50ms 刷新）时会影响响应性，得主动节流或降级为 Dispatcher.BeginInvoke 配合 Background 优先级。