为什么ASP.NET等待await client.SendAsync完成才响应新页面请求？

1. 核心根源：ASP.NET Framework 会话状态独占锁 #

默认配置下，ASP.NET Framework 会为每个携带有效Session标识的用户请求加独占写锁：只要前一个请求还没有执行完成、释放锁，同一个用户的所有后续请求都会进入排队等待状态，和请求是否异步、是否配置了ConfigureAwait(false)没有任何关系。
这个锁是绑定到用户会话（对应Cookie中的ASP.NET_SessionId）的，不是绑定到处理线程的，所以哪怕异步方法已经把原始请求线程释放回线程池，只要请求本身还没执行完毕，锁就不会释放。

2. 对ConfigureAwait(false)的作用误解 #

ConfigureAwait(false)的唯一作用是：控制await操作完成后，后续代码不需要回到原来的ASP.NET请求同步上下文执行，以此减少上下文切换开销、降低死锁概率。它不会让当前请求提前结束，也不会提前释放会话锁，所以完全不会影响后续请求的排队逻辑。

方案1：调整Session状态行为 #

如果控制器/Action不需要读写Session，可以给对应控制器或者Action添加特性，关闭独占锁：

// 标记为只读Session，不会加独占锁，同用户请求可并行
[SessionState(SessionStateBehavior.ReadOnly)]
public class YourController : Controller
{
    // Action 逻辑
}

如果完全不需要用到Session，可以标记为SessionStateBehavior.Disabled，性能更好。

方案2：异步化长耗时任务 #

对于生成报表、发邮件这类不需要用户等待结果的长耗时任务，不要同步放在请求流程中执行：

• 收到请求后先把任务加入后台队列，立即返回响应告知用户"处理中"
• 后台线程异步执行任务，执行完成后再通过站内通知、邮件等方式告知用户结果
  这样不会长时间占用会话锁，用户可以正常浏览其他页面。

方案3：确认IIS Express配置 #

开发环境下的IIS Express默认对同站点请求的并发数限制较低，你可以修改IIS Express配置，将最大并发请求数调整到合理值，避免开发环境的额外限制影响测试。

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