Dispatcher.Invoke 同步执行会阻塞调用线程，适合需立即获取结果的场景；BeginInvoke 异步但已过时；InvokeAsync 是推荐方案，返回 Task 支持 await，需注意线程上下文与异常处理。
Dispatcher.Invoke 是同步执行，会阻塞调用线程直到 UI 线程处理完
当你在非 UI 线程（比如后台任务）中修改 WPF 控件，必须通过 Dispatcher 调度到 UI 线程。用 Invoke 时，当前线程会停住，等 UI 线程执行完委托才继续往下走。
常见错误现象：在循环里反复调用 Invoke 更新进度条，界面卡顿、响应变慢，甚至看起来“假死”——其实不是崩溃，是调用线程被一个个堵住了。
- 适合场景：需要立刻拿到执行结果，比如读取某个控件的
ActualWidth或触发一次必须完成的布局更新 - 参数差异：
Invoke支持重载指定超时（TimeSpan），超时会抛TimeoutException - 性能影响：频繁调用会显著拖慢后台逻辑，尤其在高频率数据推送（如传感器采样）中要特别小心
Dispatcher.BeginInvoke 是异步执行，不等待 UI 线程完成就返回
BeginInvoke 把委托“扔进”UI 线程消息队列后立刻返回，调用线程不会停。它更像发个通知：“请稍后处理这个”，自己该干啥干啥。
常见错误现象：调用 BeginInvoke 后立即访问刚创建的控件字段，发现还是 null；或者更新了 TextBlock.Text，但下一行就去断言其值，结果断言失败——因为赋值还没发生。
- 适合场景：纯状态更新类操作，比如刷新日志列表、改变按钮
IsEnabled、触发动画，不需要立刻读取结果 - 返回值是
DispatcherOperation，可调用.Wait()强制同步（但这就退化成Invoke的行为） - 兼容性注意：.NET 6+ 中
BeginInvoke已标记为 [Obsolete]，推荐改用InvokeAsync（返回Task，语义更清晰）
InvokeAsync 是 .NET 5+ 推荐的现代替代方案
InvokeAsync 返回 Task，支持 await，既避免了 Invoke 的阻塞，又比 BeginInvoke 更容易控制执行时机和错误处理。
使用场景错位时的问题：用 await Dispatcher.InvokeAsync(...) 看似“异步”，但如果在 UI 线程上调用它，会同步执行（无调度开销），而你在后台线程 await 它，就会引发跨线程上下文切换开销——不是 bug，但可能比预期慢。
- 必须 await 才能确保执行完成；不 await 就等同于
BeginInvoke - 异常会包装在
Task中，需用try/catch包裹 await 表达式，不能只 try 外层 - 和
Invoke一样支持优先级枚举（DispatcherPriority），比如设为Background可降低对用户交互的干扰
await Dispatcher.InvokeAsync(() =>
{
statusText.Text = "Processing...";
}, DispatcherPriority.Normal);
容易被忽略的线程上下文陷阱
最隐蔽的问题不是选错方法，而是误判“当前是否在 UI 线程”。直接调用 Dispatcher.CheckAccess() 比硬编码判断更可靠。
比如在 Loaded 事件里启动一个 Task.Run，然后在里面调用 Dispatcher.Invoke ——看着合理，但如果窗体还没完全初始化好，Dispatcher 可能为 null，或引发 InvalidOperationException: “The calling thread cannot access this object because a different thread owns it.”
- 永远先检查
if (Dispatcher?.CheckAccess() == true)，再决定是否调度 - 不要在构造函数里保存
Dispatcher引用，应在Loaded之后或首次访问时惰性获取 - WPF 的
Dispatcher和 WinForms 的Control.Invoke行为相似，但对象模型不同，混用会导致编译失败或运行时异常
