C#中Task.WhenAll后用await还是.Result？生产环境异常排查

核心结论 #

Task.WhenAll之后用await获取任务结果完全没问题，改用.Result反而可能触发死锁，你遇到的计数全0问题和await无关，得从其他方向排查。

为什么await是安全的？ #

Task.WhenAll会等待所有传入任务执行完毕，之后再await单个任务，本质就是直接拿已完成任务的结果，不会有额外等待或状态异常。await是提取任务结果的安全方式，和.Result在结果获取上等价，但await不会阻塞线程，也不会引发死锁风险。

计数全0的可能原因 #

• GetDestinationPax方法逻辑问题：比如并发调用时参数被意外修改（比如destinationFacet是非线程安全的共享变量）、内部查询逻辑有并发漏洞，或者某些场景下确实无符合条件的数据，但被误判为异常情况。
• 未处理的任务异常：如果某个任务抛出异常，Task.WhenAll会把异常包装成AggregateException，要是没捕获这些异常，后续代码可能执行异常，甚至返回空集合（导致计数为0）。建议添加异常捕获：

  try
  {
      await Task.WhenAll(inHouseDestinations, arrivalsDestinations, arrivalsTomorrowDestinations, departuresDestinations);
  }
  catch (AggregateException ex)
  {
      foreach (var innerEx in ex.InnerExceptions)
      {
          // 记录日志或处理异常
      }
  }
  

• 变量引用错误：你的代码里arrivalsSummary用到了arrivalsResorts和arrivalsProperties，但前面只定义了arrivalsDestinations这类变量，这明显是笔误。如果这些变量对应的任务没被正确启动或等待，就会返回默认空值，导致计数为0。

.Result的风险 #

在ASP.NET Framework、WinForms这类有同步上下文的环境中，调用.Result会阻塞当前线程，而任务可能需要在同一上下文执行完成，直接导致死锁。就算在无上下文环境中，.Result会直接抛出任务异常（而非包装成AggregateException），增加异常处理的复杂度。所以绝对不建议用.Result替代await。

排查建议 #

1. 检查GetDestinationPax的实现，确认并发调用时有没有数据竞争或逻辑漏洞，比如是否共享了非线程安全的资源。
2. 给每个任务添加日志，记录输入参数和返回结果，看计数为0时对应的任务输入是否正确，是否确实无数据。
3. 排查代码中的未捕获异常，尤其是任务执行过程中的异常，这些异常可能导致任务结果未正确生成。

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