声明为async但无内部异步调用的方法会产生哪些危害？

你给出的无await操作的async方法示例如下：

public async Task<int> NotReallyAsynchronous() {
    // Some code... var someInt = ...;
    return someInt;
}

除了链式await调用的问题外，该写法还存在以下明确风险：

• 不必要的性能开销：编译器会为所有带async修饰符的方法自动生成异步状态机类，哪怕方法内部没有任何await逻辑，状态机的实例化、初始化、生命周期管理也会带来固定的CPU开销和堆内存分配。对于值类型的返回值，状态机还会产生额外的装箱开销。相比之下，移除async修饰符后直接返回Task.FromResult(someInt)的开销要低得多，在.NET Core 2.0及以上版本中，常见小范围整型、布尔值等返回值的Task.FromResult还会命中框架内置的缓存，几乎没有额外分配。
• 异常处理逻辑异常：带async修饰符的方法会自动将所有内部异常包装到返回的Task对象中，只有await该Task时才会抛出异常，且异常栈跟踪会被状态机重写，无法直接定位到原始抛出位置，大幅提升排查难度。如果调用方未await该方法，内部抛出的异常会成为未观察到的Task异常：.NET Framework中会直接触发进程崩溃，.NET Core中虽然默认不会终止进程，但也会留下未处理异常记录，埋下稳定性隐患。
• 资源生命周期异常：如果方法内部使用了IDisposable类型的局部对象、非托管资源，async状态机的异步上下文捕获逻辑会延长这些对象的生命周期，本该在方法执行完成后立即释放的资源会被状态机持有，直到返回的Task对象被GC回收才会释放，高并发场景下容易引发资源耗尽问题。
• 语义误导：async关键字的明确语义是「该方法包含异步IO逻辑，执行过程中会让出线程」，无异步逻辑却加async修饰符会误导后续维护的开发者，误以为该方法是IO密集型异步方法，从而做出错误的调用决策（比如不必要地用Task.Run包裹、调整线程池配置适配异步逻辑），提升代码维护成本。

正确修改方案 #

直接移除async修饰符，将返回值用Task.FromResult包装即可，修改后的代码如下：

public Task<int> NotReallyAsynchronous() {
    // Some code... var someInt = ...;
    return Task.FromResult(someInt);
}

如果方法内部可能抛出异常，可以用Task.FromException显式包装异常，保持返回Task的接口契约不变，同时完全消除async带来的所有额外问题。

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