我从这个问题中获得了 async/await-on-ASP.NET 的好处的变体。
我的理解是异步与并行不是一回事。所以，在 Web 服务器上，我想知道 async/await 给 ASP.NET 页面带来了多少好处。
IIS+ASP.NET 不是真的很擅长为请求分配线程吗？如果一个页面忙于等待资源，服务器将切换到处理另一个有工作要做的请求？
池中可供 ASP.NET 使用的线程数量有限 - async 是否更有效地使用它们？
正如 Skeet 先生在回答上述问题时指出的那样，我们并不是在谈论阻塞 UI 线程。我们已经是多线程的，并且在所有请求的任务完成之前无法完成 Web 响应，无论是否异步，对吧？
我想归根结底是这样的：
在 ASP.NET 页面中异步读取资源（例如文件或 DB 请求）与阻止它有什么好处？
如果一个页面忙于等待资源，服务器将切换到处理另一个有工作要做的请求？
我不这么认为。如果是这样的话，我会感到非常惊讶。这在理论上是可能的，但非常复杂。
池中可供 ASP.NET 使用的线程数量有限 - async 是否更有效地使用它们？
是的，因为当您执行await某些操作时，该请求的线程会立即返回到池中。
我们已经是多线程的，并且在所有请求的任务完成之前无法完成 Web 响应，无论是否异步，对吧？
那是对的。async在服务器场景中，就是要消除线程池上的压力。
在 ASP.NET 页面中异步读取资源（例如文件或 DB 请求）与阻止它有什么好处？
绝对地！
如果您阻止文件/服务调用/db 请求，则该线程将在该操作期间使用。如果您await是文件/服务调用/db 请求，则该线程将立即返回到线程池。
一个（真的很酷！）结果是您可以有一个正在进行的请求，并且当它（a）等待某些操作时，没有线程为该请求提供服务！零线程并发，如果你愿意的话。
await当操作完成时，该方法在线程池中的一个（可能不同的）线程上恢复。
总之：async比线程更好地扩展，所以服务器端肯定有好处。