关于本文
本文是通过利用生成式 AI 的自动化流程创建的。我们查阅了 Microsoft Learn 上关于 WPF 线程模型（threading model）和 PowerShell.BeginInvoke 的官方资料，并将其整理成一个极简的尝试，旨在不长时间阻塞 UI 线程的前提下观察另一个管道的完成情况。验证状态：📘 已确认 Microsoft 官方规范・未在 Windows 实机上验证
当使用 PowerShell 制作 WPF/XAML 工具时，如果在按钮的 Click 处理中直接编写 Start-Sleep 或繁重的处理，界面有时会看起来“卡死”了。这是因为 WPF 的输入、渲染与处理任务在争夺同一个 UI 线程。
本次尝试的成功条件： 在持续 3 秒的模拟处理期间依然能够操作 WPF 窗口，并且在处理完成后显示 [SUCCESS]。
冒烟测试：首先“不等待另一个管道直接开始”
核心思路的最简部分如下。
$worker = [PowerShell]::Create()
[void]$worker.AddScript({
Start-Sleep -Seconds 3
'background work finished'
})
$asyncResult = $worker.BeginInvoke()
"[START] IsCompleted = $($asyncResult.IsCompleted)"
BeginInvoke() 并不是等待其完成的同步调用。此后，UI 端只需进行简短的处理，便能观察其完成状态。
在 WPF 中，Dispatcher 按顺序处理 UI 任务
WPF 的 UI 对象与 Dispatcher 绑定。如果在 Click 事件中执行较长的同步处理，在此期间 Dispatcher 将难以处理后续的渲染和输入。
sequenceDiagram
participant U as User
participant UI as UI thread / Dispatcher
participant W as Worker pipeline
U->>UI: Button Click
UI->>W: BeginInvoke()
W-->>W: 3秒の処理
UI-->>U: 描画・ドラッグを継続
UI->>W: IsCompletedを短く確認
W-->>UI: 完了
UI-->>U: [SUCCESS] を表示
关键不在于“使用异步这个词”，而在于不在 UI 线程中长时间等待。
使用 DispatcherTimer 观察完成状态
在可复用的示例中，以 200ms 的间隔运行 DispatcherTimer，并仅对 IsCompleted 进行简短检查。完成后，通过 EndInvoke() 获取结果。
概念部分的形式如下。
$timer.Add_Tick({
if (-not $asyncResult.IsCompleted) {
return
}
$timer.Stop()
try {
$result = $worker.EndInvoke($asyncResult)
$statusText.Text = "[SUCCESS] $($result -join ', ')"
}
catch {
$statusText.Text = "[FAILED] $($_.Exception.Message)"
}
finally {
$worker.Dispose()
}
})
EndInvoke()如果在开始处理后立即调用它，结果还是会等待其完成。确认完成后再回收结果执行顺序是观察的重点。
修改一个地方试试
将可复用示例中的下一个值从 3 秒更改为 6 秒。
Start-Sleep -Seconds 6
确认等待时间翻倍后是否仍能拖动窗口。这样更容易理解这并非“因为只有 3 秒所以偶然没有卡死”，而是分离了 UI 与工作线程（worker）的结果。
不要从后台直接修改 UI
即使能够在单独的管道中运行处理，工作线程也不能随心所欲地修改 WPF 控件。UI 对象具有线程关联性（thread affinity）。
在本示例中，工作线程仅返回结果，而 StatusText 的更新是在 UI 端的 DispatcherTimer 中进行的。
直到关闭与善后也属于尝试的一部分
关闭窗口时如果只留下处理程序运行会很麻烦。在可复用版本中，关闭时会停止计时器，如果工作线程仍在运行，则会尝试停止并进行 Dispose() 处理。
Window Close
├─ DispatcherTimer.Stop()
└─ workerが存在
├─ Stop()
└─ Dispose()
实现异步化后，不仅是“开始”，取消、异常以及结束时的善后工作也都将纳入设计范围。
失败与边界条件
WPF 是一项面向 Windows 的技术，并非在所有 PowerShell 环境下前提条件都完全相同
不要将 WPF 控件直接传递给工作线程进行直接更新
如果在 DispatcherTimer 的 Tick 本身中编写繁重的处理，UI 仍会再次卡顿
实际处理是属于 CPU 密集型、I/O 密集型还是外部 API 调用，会决定采用哪种合适的并行处理方式
在生产工具中，需要添加取消（cancel）、超时（timeout）和错误详情（error details）
如果在工作中实际使用
这在带有“虽然是 PowerShell 但带有图形界面”的内部辅助工具中效果显著。例如以下处理：
读取大量 CSV 文件的同时显示进度
在检查多台 PC 或 URL 状态的过程中也能按下取消按钮
在等待 API 响应期间不让界面卡死
将 Excel 或文件的读取检查后台化，仅将结果返回给界面
越是面向文职人员的工具，越容易让人觉得“处理时没有响应＝坏了”，因此内部技术的改进会直接提升操作体验。
