异步方法中处理同步代码的最优方案探讨

我正在实现一个消息调度器/处理器，要求每个处理器必须实现如下接口：

Task<Result> HandleAsync(IEvent myevent)

示例异步处理器代码：

public async Task<Result> HandleAsync(CustomerChangedEvent ev)
{
    await DoSomethingAsync();
    ...
    return myResult;
}

但有些消息只需要执行同步代码，这时如果用async修饰方法却没有await会触发编译器警告。我目前的做法是在代码里加一句await Task.CompletedTask;，运行正常，但不确定这么做有没有弊端。

另一种方案是去掉async关键字，直接返回Task.FromResult(myResult)。

想知道这两种方案（或其他方案）各有什么优势？尤其从性能角度出发——比如声明async方法会不会产生显著开销？我个人更倾向第一种方案，总觉得Task.FromResult可读性较差，虽然第一种多了一条冗余指令。

补充说明：
我实现的是发件箱消息处理器，用来处理包含不同消息的队列，部分消息需要异步操作，部分不需要。每种消息类型对应一个实现上述接口的处理器类。我希望新增消息类型的处理步骤尽可能简单：只需要创建实现指定接口的处理器类，注册到调度器（也可以通过反射自动注册）。
调度器读取队列时，会根据消息类型调用对应处理器的HandleAsync方法。或许还有更优的方案，让处理器可以根据需求定义同步或异步方法。

一、两种现有方案的优劣对比 #

1. 方案一：保留async，添加await Task.CompletedTask; #

• 优势：
  • 代码风格统一：和异步处理器写法完全一致，新增处理器时无需切换写法逻辑，降低认知成本
  • 可读性高：符合async/await的惯用写法，其他开发者能快速理解代码意图
  • 扩展性好：后续若要将同步逻辑改为异步，直接添加真实await调用即可，无需修改方法签名或返回逻辑
• 弊端：
  • 微小性能开销：async方法会生成状态机，现代编译器优化后开销极小，但高频调用场景下会产生可忽略的额外内存分配（状态机实例）和CPU开销
  • 冗余代码：await Task.CompletedTask;是纯粹为消除警告添加的无意义代码

2. 方案二：去掉async，返回Task.FromResult(myResult) #

• 优势：
  • 性能最优：无状态机生成，直接返回已完成的Task实例，几乎无额外开销，适合高频调用的同步处理器
• 弊端：
  • 可读性差：Task.FromResult的写法不符合常规同步代码直觉，需要开发者理解“用Task包装同步结果”的意图
  • 扩展性差：后续若要改为异步逻辑，需重新添加async关键字并调整返回语句，改动成本更高
  • 风格不一致：与异步处理器写法差异明显，新增处理器时需判断同步/异步场景，增加心智负担

二、更优折中方案：基类封装 #

如果想兼顾代码一致性和性能，可以为同步处理器提供基础封装类，隔离Task包装逻辑：

public abstract class SyncEventHandlerBase<TEvent> : IEventHandler<TEvent> where TEvent : IEvent
{
    // 定义纯同步处理方法
    protected abstract Result Handle(TEvent ev);

    // 实现接口的异步方法，自动处理Task包装与异常捕获
    public Task<Result> HandleAsync(TEvent ev)
    {
        try
        {
            var result = Handle(ev);
            return Task.FromResult(result);
        }
        catch (Exception ex)
        {
            // 保持与async方法一致的异常处理行为
            return Task.FromException<Result>(ex);
        }
    }
}

同步处理器只需继承基类，实现纯同步逻辑即可：

public class CustomerCreatedHandler : SyncEventHandlerBase<CustomerCreatedEvent>
{
    protected override Result Handle(CustomerCreatedEvent ev)
    {
        // 纯同步业务逻辑
        DoSomethingSync();
        return new Result();
    }
}

异步处理器则直接实现原接口，保持async/await写法：

public class CustomerChangedHandler : IEventHandler<CustomerChangedEvent>
{
    public async Task<Result> HandleAsync(CustomerChangedEvent ev)
    {
        await DoSomethingAsync();
        return new Result();
    }
}

该方案的核心优势：

• 同步处理器写法极简，完全是常规同步代码，可读性拉满
• 异步处理器保持原有写法，整体风格统一
• 底层自动处理Task包装和异常捕获，与async方法行为完全一致
• 性能与方案二持平，无状态机开销

三、关于async方法的性能开销 #

现代.NET编译器对async方法的优化已非常成熟，绝大多数场景下状态机的开销可以忽略不计。只有在极端高频调用（如每秒百万次以上）的场景下，才需要考虑去掉async节省开销。如果你的消息队列处理频率未达到这个量级，方案一的微小开销完全可以接受，换来的是更好的代码可维护性。

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