ASP.NET Core中实现可等待的缓存接口：是否应使用await Task.Delay(0)或忽略编译器警告？

这个问题在处理同步/异步混合的接口实现时特别常见，我给你梳理几个更优雅的解决方案，比用Task.Delay(0)或者忽略警告靠谱得多：

1. 用框架提供的已完成任务替代Task.Delay(0) #

Task.Delay(0)本质上是个“伪异步”操作——它会把任务塞进线程池队列再立即执行，完全没必要额外增加这层调度开销。微软框架已经提供了更高效的方式来返回已完成的任务：

• 有返回值的方法用Task.FromResult<T>
• 无返回值的方法用Task.CompletedTask

这样你的内存缓存实现可以改成这样：

public class InMemory : ITokenCache
{
    private readonly IMemoryCache _memoryCache;

    public InMemory(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache;
    }

    public Task<string> GetToken(string key)
    {
        // 直接返回包含结果的已完成任务，无额外调度
        return Task.FromResult(_memoryCache.Get(key) as string);
    }

    public Task<string> SetToken(string key, string value)
    {
        _memoryCache.Set(key, value);
        return Task.FromResult(value);
    }

    public Task DeleteToken(string key)
    {
        _memoryCache.Remove(key);
        // 返回框架预定义的已完成任务实例，避免重复创建对象
        return Task.CompletedTask;
    }
}

这种方式不仅能彻底消除编译器警告，还能保证最佳性能——没有多余的线程池调度，同时完全符合异步方法的签名要求，上层调用方可以统一用await调用，根本不用关心底层是同步还是异步实现。

2. 别忽略编译器警告（划重点） #

绝对不建议直接忽略警告！编译器的这个警告是在提醒你：你标记了async但没有实际的异步操作，这会让方法同步执行却被包装成Task，虽然功能上能跑，但会让调用方产生误解——以为这是不会阻塞线程的异步方法，但实际上内存缓存的操作还是同步阻塞当前线程的。而且忽略警告也会让代码维护者困惑，不知道这是故意的还是遗漏了什么。

3. 要不要拆分同步/异步接口？ #

如果你的系统里有大量场景只需要同步缓存操作，也可以考虑拆分出ISyncTokenCache和IAsyncTokenCache两个接口，但这会增加上层调用的复杂度——调用方需要根据场景选择不同的接口。除非你有明确的性能优化需求，否则保持单一异步接口，用上面的Task.FromResult方式实现同步版本，是更简洁的方案。

总结一下：最优解就是用Task.FromResult和Task.CompletedTask来实现同步缓存的异步接口，既解决了警告问题，又没有多余性能开销，还能保持接口的一致性。

备注：内容来源于stack exchange，提问作者Zombies are Real