我想知道如果不是代码的所有部分都是异步的，那么使用异步 http 请求会带来多少好处。
让我们考虑以下场景：1) 异步 http 请求阻塞同步数据库调用，2) 同步 http 请求等待异步数据库调用。
1) Web Api 支持异步操作方法，但是如果我在处理请求时进行同步数据库调用，那么线程会阻塞调用，我将无法获得异步可以给我带来的更好的线程经济性的好处还是什么？
2) 如果我有一个等待异步数据库调用的同步 ServiceStack 服务调用，那么会发生什么？我假设保留了一个线程来处理整个同步 http 请求，并且当该线程等待异步调用时，它仍然保留给 Web 请求或什么？
基本上我的问题可以归结为：如果不是所有的 IO 调用都是异步的，是否有任何理由使用异步？
在服务器端，部分解决方案通常没有任何好处async。
1) Web Api 支持异步操作方法，但是如果我在处理请求时进行同步数据库调用，那么线程会阻塞调用，我将无法获得异步可以给我带来的更好的线程经济性的好处还是什么？
正确的。一旦您进行同步（阻塞）数据库调用，您就在该调用期间占用了一个线程。因此，您将获得的好处async不适用。
2) 如果我有一个等待异步数据库调用的同步 ServiceStack 服务调用，那么会发生什么？我假设保留了一个线程来处理整个同步 http 请求，并且当该线程等待异步调用时，它仍然保留给 Web 请求或什么？
这与同步数据库调用相同。在幕后，同步数据库调用异步执行实际调用，然后阻塞调用线程直到它完成。所以在调用期间你仍然有一个线程被阻塞，你没有得到任何async好处。
基本上我的问题可以归结为：如果不是所有的 IO 调用都是异步的，是否有任何理由使用异步？
还有一些更晦涩的场景。您可以使用Task.WhenAll执行有限类型的并发，这async比其他形式的异步并发更容易使用。但如果你没有全async栈，这是我能想到的唯一好处。
它基本上归结为在异步调用完成时调用代码可以做什么。你的第一个例子很适合这个。当调用 save 方法时，UI 可以做其他事情。方法内幕后发生的事情并不重要......控制权已交还给应用程序以继续其方式。
您的第二个示例仅意味着 servicestack 服务可以在完成异步数据库调用时执行某些操作。但是，如果它没有做任何事情，那么就没有任何真正的理由使用异步调用开始。
异步方法在其工作负载期间所做的事情并不像调用应用程序在调用期间所做的事情那么重要。