WPF中Dispatcher.InvokeAsync搭配ContinueWith未等待异步方法问题

这个问题的核心是**ContinueWith和异步委托（async lambda）的交互方式导致嵌套任务未被正确等待**，咱们一步步拆解：

为什么UpdateChartsWithValuesAsync没被等待？ #

当你给ContinueWith传入一个async t => ...的lambda时，这个lambda本身返回的是一个Task（因为异步方法/委托都会返回Task）。这时候ContinueWith的返回值就变成了Task<Task>——外层任务代表lambda的执行（到它返回内部Task为止），内层任务才是UpdateChartsWithValuesAsync的执行过程。

而你的代码里只await了外层的Task<Task>，它只会等待lambda启动并返回内部Task，不会等待内部Task执行完成。这就导致程序继续往下走，但UpdateChartsWithValuesAsync还在后台跑，自然会引发后续的同步问题。

两种可行的修复方案 #

方案1：用Unwrap()解开嵌套任务 #

Unwrap()方法可以把Task<Task>转换成一个普通的Task，这个Task会等待内部的异步操作完成，修改后的代码如下：

await Dispatcher.InvokeAsync(() => 
{ 
    ChartViewModels.Clear(); 
    ChartViewModels.AddRange(initializedCharts); 
}, DispatcherPriority.DataBind, mCancellationToken.Token).Task
.ContinueWith(async t => await UpdateChartsWithValuesAsync(chartsToInitialize, ChartViewModels).ConfigureAwait(false), 
    mCancellationToken.Token, 
    TaskContinuationOptions.OnlyOnRanToCompletion, 
    TaskScheduler.Current)
.Unwrap() // 关键：解开嵌套的Task<Task>，让await等待内部异步方法完成
.ConfigureAwait(false);

方案2：抛弃ContinueWith，用纯await链（更推荐） #

在有async/await的场景下，ContinueWith其实是过时的写法——await本身就是为了简化异步流程控制设计的，可读性和安全性都更高。直接把两个异步操作用await串联起来就行：

// 等待Dispatcher操作完成
await Dispatcher.InvokeAsync(() => 
{ 
    ChartViewModels.Clear(); 
    ChartViewModels.AddRange(initializedCharts); 
}, DispatcherPriority.DataBind, mCancellationToken.Token).ConfigureAwait(false);

// 再等待更新方法完成
await UpdateChartsWithValuesAsync(chartsToInitialize, ChartViewModels).ConfigureAwait(false);

这里要注意：Dispatcher.InvokeAsync返回的DispatcherOperation本身就是可等待的，不需要额外访问.Task属性，直接await即可。

额外说明 #

• 关于ConfigureAwait(false)：它的作用是避免捕获当前的UI上下文，对于后台数据更新类的操作（比如你的UpdateChartsWithValuesAsync）是合适的，可以减少线程切换开销。如果后续操作需要回到UI线程，再去掉这个配置即可。
• 在.NET Framework 4.7中，async/await的支持已经很完善，除非有特殊的复杂任务调度需求，否则尽量用await代替ContinueWith，能避免很多嵌套任务、上下文捕获的坑。

内容的提问来源于stack exchange，提问作者Krusty