使用await触发Sys.WebForms.PageRequestManager超时，换Result正常，二者有何区别

二者核心运行机制差异 #

• await 逻辑：默认会捕获当前线程的SynchronizationContext（同步上下文），异步操作完成后，会回到捕获的同步上下文继续执行后续代码。ASP.NET Framework（Web Forms所属框架）的同步上下文是排他的，同一时间只允许一个线程进入执行。
• .Result 逻辑：直接阻塞当前调用线程，同步等待异步任务完成，不会捕获原同步上下文，异步操作的后续执行会直接在线程池线程上完成，不需要回到原上下文。

超时异常的根因 #

你遇到的是ASP.NET Web Forms下典型的同步上下文死锁问题：

你的PostAsync方法上游调用方肯定是同步等待执行结果的（比如在Page后台事件中没有加await，直接调用PostAsync(...).Wait()或者直接同步获取结果），此时调用线程已经占住了ASP.NET同步上下文。
当你使用await client.PostAsync时，await捕获了当前被占住的同步上下文，HTTP请求完成后需要拿到这个同步上下文才能继续执行PostAsync的后续代码，但同步上下文已经被上游等待的线程占住了，二者互相等待形成死锁，最终超过Sys.WebForms.PageRequestManager的超时阈值，抛出Sys.WebForms.PageRequestManagerTimeoutException异常。
换成.Result后，client.PostAsync的后续执行不需要回到被占住的原同步上下文，直接在线程池线程完成执行，不会触发死锁，因此可以正常返回结果。

优化建议 #

当前用.Result只是临时绕过方案，并不是最优解，存在异常堆栈丢失、其他场景仍可能死锁的问题，推荐做如下优化：

1. 全链路异步改造：Web Forms的页面事件本身支持async void声明，把上游调用方也改成异步，全程用await调用异步方法，不要混合同步等待（Wait()/Result）和await，从根源消除死锁可能。
2. 修正静态HttpClient的用法：静态HttpClient的BaseAddress、DefaultRequestHeaders属性是线程不安全的，你在每次循环中修改这些属性，高并发场景下会出现属性值错乱的问题，建议每次请求单独构造HttpRequestMessage，单独设置请求地址、头信息，不要修改静态实例的全局属性。

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