Dispatcher.Invoke 同步阻塞后台线程直至 UI 线程执行完委托，适用于需返回值或确保 UI 操作完成的场景；Dispatcher.BeginInvoke 异步提交委托且不等待，但无法直接获取返回值，.NET 6+ 中已过时，推荐使用 InvokeAsync。
Dispatcher.Invoke 会阻塞当前线程直到 UI 线程执行完委托
当你在后台线程调用 Dispatcher.Invoke，它会把委托封送到 UI 线程，并**同步等待执行完成**。这意味着：后台线程会卡住，直到 UI 线程处理完那个委托——这对响应性要求高的场景（比如频繁更新进度条）可能造成明显卡顿。
适用场景：
- 必须拿到委托执行后的返回值（Invoke 支持泛型返回）
- 需要确保某段 UI 操作（如弹窗、焦点设置）完成后再继续逻辑
- 调用后立刻依赖 UI 控件状态（比如读取 TextBox.Text 修改结果）
示例：
string result = Dispatcher.Invoke(() => { return myTextBox.Text; });
Dispatcher.BeginInvoke 是异步的，不等待 UI 线程执行结束
Dispatcher.BeginInvoke 把委托加入 UI 线程的消息队列后就立即返回，**后台线程不会停**。它返回一个 DispatcherOperation 对象，可用于检查状态或取消（但不能直接获取返回值）。
常见误用：
- 以为调用完就能立刻读取 UI 控件新值（实际可能还没执行）
- 在 BeginInvoke 后紧接着做依赖 UI 状态的判断，导致逻辑错乱
示例：
Dispatcher.BeginInvoke(new Action(() => { myLabel.Content = "Done"; }));如果需要“执行完再通知”，得用
DispatcherOperation.Completed 事件，而不是轮询或 Sleep。
参数差异和 .NET 版本兼容性要注意
.NET Framework 和 .NET Core / .NET 5+ 的 Dispatcher API 不完全一致：
-
Invoke(Action)和BeginInvoke(Action)始终可用 -
Invoke只在 .NET Framework 和较新 .NET 中支持；旧版 .NET Core 可能需用(Func ) Invoke+ out 参数模拟 -
BeginInvoke在 .NET 6+ 中已标记为过时（obsolete），推荐改用Dispatcher.InvokeAsync（返回Task，可 await）
如果你项目目标是 .NET 6+，优先写：
await Dispatcher.InvokeAsync(() => myButton.IsEnabled = false);
UI 线程阻塞风险比想象中更隐蔽
很多人只注意“别在 UI 线程里跑耗时操作”，却忽略 Invoke 是把耗时操作又拉回 UI 线程执行。比如：
错误写法：
Dispatcher.Invoke(() => { HeavyCalculation(); UpdateChart(); });这会让 UI 线程卡死，用户连关闭窗口都点不动。
正确拆分思路：
- HeavyCalculation() 必须留在后台线程
- 只把轻量 UI 更新（如赋值、Visibility 切换）用 Invoke 或 InvokeAsync 封送
- 复杂控件（如 DataGrid 大量刷新）考虑虚拟化或批量更新模式，避免高频 Invoke
真正难的不是语法，而是判断哪部分该在后台算、哪部分必须交还 UI 线程——这个边界一旦划错，卡顿就藏在看似正确的代码里。
