控制台应用中使用async与await的优势有哪些？

• IO 密集型场景下大幅提升资源利用率
  控制台应用常用来处理批量文件读写、API 批量调用、数据库批量操作等 IO 密集型任务，同步写法会让线程在 IO 等待期间全程阻塞占用，浪费系统资源。使用 async/await 后，IO 等待阶段线程会被释放回线程池处理其他任务，无需为每个待执行的 IO 任务单独分配阻塞线程，面对大量 IO 任务时，能显著降低线程数量，减少内存开销和 CPU 上下文切换损耗。比如批量爬取 200 个网页的场景，同步写法可能需要占用几十甚至上百个线程，异步写法通常只需要 3~5 个线程就能完成相同工作量。
• 批量作业的吞吐量明显提升
  对于数据迁移、日志批量解析、批量数据上报类的批量作业任务，async/await 的非阻塞特性能让单位时间内处理的任务数量远高于同步多线程方案，尤其当任务量级过千、IO 等待占比超过 70% 时，性能差距会非常明显。
• 代码可读性和可维护性大幅优于传统异步方案
  早期控制台实现异步逻辑通常依赖 Thread、ThreadPool 或者 Task.ContinueWith 回调，多层嵌套后很容易出现回调地狱，异常处理也需要单独封装。async/await 可以让异步代码的逻辑结构和同步代码几乎一致，直接用常规的 try/catch 就能捕获异步过程中的异常，后期排查问题和修改逻辑的成本低很多。
• 无缝对接 .NET 生态原生异步 API，避免强行转同步的风险
  目前 .NET 官方类库绝大多数都优先提供异步实现，比如 HttpClient、EF Core、System.IO 下的大部分 API 都有 Async 后缀的异步版本，控制台用 async/await 可以直接调用这些原生异步 API，不需要用 .Result 或者 .Wait() 强行转同步，既避免了潜在的死锁风险，也能享受到官方优化后的异步性能。
• 长驻后台控制台服务的稳定性更高
  如果你用控制台实现消息消费、定时任务执行这类长驻后台服务，async/await 的非阻塞特性可以避免瞬时 IO 高延迟把线程池线程占满的问题，新的任务可以及时拿到空闲线程执行，服务的抗抖动能力会显著提升。

举个简单的批量读文件场景的代码对比：
同步写法：

foreach (var filePath in filePaths)
{
    var content = File.ReadAllText(filePath);
    ProcessContent(content);
}

异步写法：

foreach (var filePath in filePaths)
{
    var content = await File.ReadAllTextAsync(filePath);
    ProcessContent(content);
}

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