C#异步编程中同步调用异步方法的两种Result写法差异及规范性咨询

等价性核心结论 #

在绝大多数实际业务场景下，两种方案的执行逻辑、运行结果、风险表现完全等价，不存在本质区别。
两种写法的本质执行流程是完全一致的：

1. 同步调用Compute()方法，拿到代表异步操作的Task<string>实例
2. 在当前调用线程同步阻塞等待Task执行完成
3. 取出Task的返回值，同步返回给ParentMethod的调用方
   不管你是直接链式写Compute().Result，还是先把Task实例存到computedTask变量里再读取.Result，上述三步的执行时序、行为没有任何差异。

注：不存在所谓“存到变量的写法会提前启动Task、链式写法会延迟启动Task”的区别——async方法在被调用的那一刻就会同步执行直到遇到第一个未完成的await点，才会返回未完成的Task，这个启动逻辑和你是否存储Task变量没有任何关系。

两种方案共同存在的固有问题 #

很多技术文章反复诟病这类写法，本质上是反对“用同步方式阻塞等待异步Task”的反模式，而不是反对某一种具体的变量存储写法，两类写法共同存在的风险完全一致：

• 高概率死锁风险：在带同步上下文的运行场景下（比如传统ASP.NET、WPF/WinForms的UI线程），异步操作完成后需要回到原同步上下文执行后续逻辑，但当前线程已经因为读取.Result被永久阻塞、无法释放上下文，最终会形成互相等待的死锁。这个风险不会因为你是链式写还是先存变量就有任何变化。
• 线程资源浪费：长时间运行的异步操作执行过程中，当前线程被硬阻塞挂起，这段时间内线程无法被CPU调度去处理其他任务，会直接降低应用的整体吞吐量。
• 异常处理复杂度提升：如果Compute()执行过程中抛出业务异常，读取.Result时异常不会被直接抛出，而是会被包装成AggregateException，开发人员需要额外拆解异常对象才能拿到原始错误信息，和await直接抛原始异常的行为差异极大。

为什么普遍有“方案2写法不好”的认知偏差？ #

这类认知大多来自技术文章的以讹传讹：很多作者把“先存Task变量”这个代码形式当成了风险来源，实际上风险的根源是读取.Result的阻塞操作本身。哪怕你把代码压缩成一行链式写，上述所有风险都不会消失。
少数场景下两类写法存在极其细微的行为差异，但完全不影响实际项目使用：比如如果Compute()内部没有经过异步逻辑、在同步阶段就抛出异常，两种写法抛出异常的时机、类型也完全一致，不存在谁优谁劣。

方案1是否属于良好编程实践？ #

不属于。
方案1只是代码更短、看起来更简洁，但是所有反模式的缺陷和方案2完全一致。它本质上还是在执行“同步阻塞等待异步操作”的操作，没有任何执行层面的优势。
很多人误以为链式写.Result比存变量的写法更安全，实际上没有任何代码机制能让链式写法规避掉死锁、资源浪费、异常包装的问题，这只是一种没有实际依据的直觉判断。

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