IProgress 是进度值传递契约而非通知机制，其回调默认在 Report() 调用线程执行，跨线程需手动同步；类型选择影响语义（int 适合离散步数，double 适合连续百分比）；必须配合 CancellationToken 实现安全取消；需主动管理生命周期，避免空引用和内存泄漏。
IProgress不是“通知机制”，而是“进度值传递契约”——它本身不触发 UI 更新，也不自动跨线程调度；你传进去的实例，只负责把调用原样转发给构造时绑定的回调（或事件），至于这个回调在哪个线程执行、是否安全访问 UI 控件，全由你控制。
Progress 的回调默认在调用 Report() 的线程上执行
这是最容易踩坑的地方：如果你在
里调用
，而
是在 UI 线程创建的，那回调（比如更新
）就会在后台线程执行 → 直接抛
：“线程间操作无效”。
解决方法只有两种：
显式指定同步上下文：用
构造时传入 UI 线程的
，但 WinForms/WPF 已自动捕获，通常不用手动做
确保
只在 UI 线程调用：把耗时逻辑和
拆开，用
+
或
包裹回调逻辑（不推荐）
更稳妥的做法：在
构造后，直接用
事件绑定 UI 更新逻辑，系统会自动封送到 UI 线程（WinForms/WPF 默认行为）
IProgress 和 IProgress 的语义差异
别只看类型，要看业务含义：
常用于离散步骤（如“第 3/10 步”），
表示当前完成第 3 步，
需外部约定（比如 10）
更适合连续百分比（0.0–100.0），
可直接赋给
（只要
）
混用会导致精度丢失或 UI 显示错乱：比如用
报告 0–100 之间的值，但实际步长是 3，最后一步可能卡在 99 不到 100
Task.Run 里 Report 进度必须配合 CancellationToken
单纯用
是危险的：用户点“取消”时，后台线程还在跑，
可能继续发，UI 可能收到过期进度甚至崩溃。
正确姿势是把
和
一起传入：
C知道
CSDN推出的一款AI技术问答工具
下载
注意：
比
安全得多，前者可被取消且不阻塞线程。
Progress 的生命周期管理容易被忽略
实例不是一次性的，它持有对回调的引用。如果回调里捕获了窗体实例（比如
），而窗体已关闭，但后台任务还在运行并持续
，就会造成内存泄漏 + 空引用异常。
务必在任务结束或窗体关闭时做清理：
WinForms：在窗体
事件中，设
，并在
前加空检查
更健壮做法：用弱引用包装回调，或改用
事件处理（仅限 UI 层）
不要依赖 GC ——
不实现
，也没必要 Dispose
最常被跳过的细节是：没人检查
是否为
就直接
，尤其在异步任务被快速启停的场景下，空引用异常几乎必然发生。
ProgressReport()Task.Runprogress.Report(50)ProgressProgressBar.ValueInvalidOperationExceptionProgress(action) SynchronizationContextReport()Report()awaitInvokeDispatcher.InvokeProgressProgressChangedIProgressReport(3)MaximumIProgressReport(42.5)ProgressBar.ValueMaximum == 100intTask.Run(() => { /* loop + Report */ })Report()CancellationTokenIProgressstatic async Task DoWorkAsync(CancellationToken token, IProgress progress)
{
double total = 100;
for (int i = 0; i <= total; i++)
{
token.ThrowIfCancellationRequested(); // 关键：检查取消
progress?.Report(i);
await Task.Delay(50, token); // 延迟也支持取消
}
} Task.Delay(50, token)Thread.Sleep(50)ProgressthisReport()FormClosedprogress = nullReport()async voidProgressIDisposableprogressnullReport()