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<tresult></tresult>，支持
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行为相似，但对象模型不同，混用会导致编译失败或运行时异常
