凭借异步 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 中获得的收益很少。实际上，默认情况下您会失去性能。
在 Metro 环境中，已为您做出决定。微软（合法地）选择用开发人员的生产力换取用户体验。
所以这不是一个明确的决定。在这一点上，利弊都相当薄弱。出于这个原因，我避免给出明确的建议。这在很大程度上取决于具体情况。
我建议async在您有自然异步操作时使用，否则使用同步代码。确实async会稍微慢一些，但在大多数情况下，它就像“打开悍马中的收音机”一样慢。
在 UI 程序中，async提高响应能力。在服务器应用程序中，async增加了可扩展性。
AFAIK Windows 文件 I/O 内部是异步的。天真地看着这个我不清楚，为什么 .NET 中的异步文件 i/O 应该比同步慢。
异步代码比较慢，因为它必须分配结构来跟踪异步操作；同步代码只使用当前线程（及其堆栈）。所以操作本身并没有变慢，但由于垃圾收集器的压力更大，整体速度略有下降。
我通常倾向于简单性和健壮性，并且只在必要时调整性能。
我同意。如果您有一个自然异步的操作（例如 I/O），请公开一个asyncAPI。如果您有一个自然同步的操作，请公开一个同步 API。Stephen Toub 在这方面有几篇很棒的博客文章（这里和这里）。