关于C# .NET中ContinueWith内使用Task.Result是否引发死锁的疑问

你的这段代码不会直接引发死锁——因为ContinueWith的回调只会在base.sendAsync返回的Task完成后才执行，此时task的状态已经是完成（成功、失败或取消），访问task.Result不会阻塞线程，也不会出现死锁场景。

但这段代码存在不少潜在问题，远不如用await的写法可靠：

• 异常处理繁琐：如果sendAsync抛出异常，task.Result会包装成AggregateException抛出，你需要手动拆解才能拿到原始异常；而用await会直接抛出原始异常，调试和处理更直观。
• 调度上下文不可控：默认情况下ContinueWith会使用TaskScheduler.Current来调度回调，可能导致回调在非预期的线程上执行（比如如果当前上下文是UI线程，可能引发线程亲和性问题）；await会自动捕获当前上下文并在回调时恢复，行为更符合预期。
• 代码扩展性差：如果后续需要在请求完成后添加更多逻辑，嵌套的ContinueWith会快速陷入“回调地狱”，代码可读性和维护性骤降；await的线性写法能保持逻辑清晰。
• 取消逻辑冗余：虽然你给ContinueWith传入了cancellationToken，但这个令牌仅用于取消回调的调度（比如回调还没开始执行时），而前置任务的取消已经由传入sendAsync的令牌处理了，写法上显得多余。

优化后的await版本代码更简洁可靠：

private async Task<HttpResponseMessage> ProcessRequest(HttpRequestMessage request, CancellationToken cancellationToken)
{
    return await base.sendAsync(request, cancellationToken);
}

如果只是单纯转发任务，甚至可以省略await直接返回base.sendAsync的结果，但保留await能让代码更清晰，也方便后续扩展业务逻辑。

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