C#编译器为何差异化处理无await的async Task与Task.CompletedTask写法？

这不是编译器遗漏的性能优化，而是C#设计团队刻意保留的行为：两种写法存在本质的可观测语义差异，强行统一编译逻辑会构成破坏性变更，直接破坏大量现有代码的运行逻辑。
编译优化的核心前提是优化前后代码的可观测行为完全一致，只要存在任何可被用户代码感知到的行为差异，再大的性能收益也不能默认开启。

两种写法的核心语义差异有两点：

• 异常抛出逻辑完全不同
  所有标记了async的方法，无论内部是否使用await，执行过程中抛出的异常都会被自动包装到返回的Task对象中，调用方法的同步阶段不会直接抛出异常；而非async直接返回Task.CompletedTask的方法，执行中抛出的异常会直接同步抛给调用方，根本不会返回Task实例。
  可以通过简单代码验证这个差异：

  // async无await版本
  public async Task ThrowTest()
  {
      throw new InvalidOperationException();
  }
  
  // 非async返回CompletedTask版本
  public Task ThrowTest()
  {
      throw new InvalidOperationException();
      return Task.CompletedTask;
  }
  

  两者调用时的行为完全不兼容：

  • 调用async版本时，var task = ThrowTest(); 这行代码不会抛出异常，异常被封装在返回的task对象中，只有执行await task或task.Wait()时才会触发异常
  • 调用非async版本时，var task = ThrowTest(); 这行代码会直接抛出异常，调用方根本拿不到返回的Task对象
    这个异常包装行为是TPL（任务并行库）的核心语义约定，大量框架、基础设施代码和业务逻辑都依赖这个行为做统一的异步异常处理，一旦编译器修改这个逻辑，会导致大面积的代码故障。

• 执行上下文流转逻辑不同
  async方法进入时会自动捕获当前执行上下文（包含AsyncLocal存储值、同步上下文等），方法内部对上下文的修改会在方法返回时自动还原，不会污染调用方的执行上下文；而非async的普通方法修改AsyncLocal等上下文数据时，修改会直接生效到调用方上下文，这个差异同样可以被业务代码明确观测到，不能被随意更改。

C#编译器已经对这种场景做了明确提示：当你编写了没有任何await表达式的async方法时，会触发CS1998编译警告，明确告知你该方法不会产生异步暂停，你可以根据实际语义需求选择处理方式：

• 如果你确实需要async方法的异常包装、上下文隔离语义，可以保留async关键字，忽略该警告
• 如果你不需要上述语义，想要避免async状态机生成的额外性能开销，手动去掉async关键字，自行返回Task.CompletedTask（无返回值场景）或Task.FromResult<T>(结果)（有返回值场景）即可。

编译器不会替开发者做语义层面的选择，因为它无法判断你写无await的async方法是待完善的半成品代码，还是刻意依赖async方法的固有语义。

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