什么是伪异步方法？为何两种Task.Run封装实现性质不同？

首先要明确：文中提到的「伪异步」评判的不是Task.Run的用法，而是对外暴露的公共API是否符合.NET的TAP（基于任务的异步模式）约定。

第一种实现是「伪异步」的原因 #

服务层对外公开的CalculateMandelbrotAsync方法后缀带Async，按照.NET生态的通用约定，所有带Async后缀的公共方法都应该是「真正的异步实现」：要么是基于IO等待的异步（不需要占用线程池线程），要么是明确告知调用方这是CPU密集型异步计算。
但这个实现的问题在于：

• 它本质是把100%同步的CPU计算硬编码包了一层Task.Run，对外假装自己是无阻塞的异步方法
• 调用方如果是高并发服务端（比如ASP.NET），调用这个方法时会误以为它不占用线程池线程，实际反而多消耗了一个线程池线程，还额外增加了线程调度的开销，反而降低服务端吞吐量
• 剥夺了调用方的选择权：如果调用方本身就想同步执行计算，还得额外调用.Result或者.Wait()，平添死锁风险

第二种实现不属于「伪异步」的原因 #

UI层的GetMandelbrot是私有方法，仅为当前UI场景服务：

• 它没有对外暴露带Async后缀的公共API，不存在误导其他调用方的问题
• 它的行为完全符合UI场景的预期：把CPU密集型计算丢到后台线程执行，避免阻塞UI线程导致界面卡死，await之后自动切回UI线程更新界面，所有逻辑都是明确符合场景需求的

为什么推荐把Task.Run放在UI层 #

服务层的方法要兼容所有调用场景：

• 如果是服务端调用计算方法，直接同步执行即可，不需要多此一举用Task.Run浪费线程池资源
• 如果是UI端调用，自己决定要不要用Task.Run丢后台即可
  把Task.Run的决定权交给调用方，才是对所有场景都友好的设计。

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