凭借异步 I/O 的优势以及现在非常容易编码和编写(使用 Await 和 TAP 方法)，我想知道我们是否应该默认使用异步，并且只在需要时使用同步来调整性能。
异步 I/O 释放调用线程并允许在等待结果时执行其他操作。另一方面，异步 I/O 比同步慢一点。
为了强制执行响应式 UI，WinRT 设计人员发现提供仅异步方法是可以接受的。
AFAIK Windows 文件 I/O 内部是异步的。天真地看着这个我不清楚，为什么 .NET 中的异步文件 i/O 应该比同步慢。
我通常倾向于简单性和健壮性，并且只在必要时调整性能。过去，我们默认使用同步，但调用某些服务以及手机等平台强制执行异步除外。我们很少使用异步进行调整。
最佳答案
在 C# 5 中使用异步 IO 变得非常容易，但仍然存在与之相关的生产力成本。例如，您需要在必要时在以前没有的地方添加新的关键字。您必须更改方法的返回类型。
如果您稍后决定某个方法应该执行 IO，则必须更改整个调用链以切换到异步。它是一种非局部的变化，传播到其他模块。
您无法分析异步 IO。分析工具什么也没有。如果您暂停调试器，则任何线程堆栈上都没有任何内容。似乎没有人在做任何事情。那是因为异步 IO 不持有线程。它只是一个数据结构(内核中的一个对象)。
该决定还取决于应用程序类型。在 WinForms 或 WPF 应用程序中，我宁愿使用异步，因为它可以很好地集成到 UI 线程中。
在 ASP.NET/WCF 设置中，主要优点是在调用长时间运行的后端服务时不会耗尽线程池。如果你没有这样的问题，而且我认为这相当罕见，那么你从异步 IO 中获得的 yield 很少。实际上，默认情况下您会失去性能。
在 Metro 环境中，已为您做出决定。微软(合法地)选择用开发人员的生产力换取用户体验。
所以这不是一个明确的决定。在这一点上，利弊都相当薄弱。出于这个原因，我避免给出明确的建议。这在很大程度上取决于具体情况。
关于.net - 我们应该切换到默认使用异步 I/O 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12793749/