ASP.NET Core中HttpContext属性的工作原理及其异步安全实现机制探究

这个问题问到点子上了——确实，线程本地存储（TLS）在异步场景下完全不适用，毕竟await之后异步方法可能在另一个线程池线程上恢复，甚至同一个线程可能同时处理多个休眠后唤醒的异步任务，那ASP.NET是怎么做到HttpContext的异步安全的呢？核心靠两个关键机制：异步本地存储（Async Local Storage） 和 执行上下文（Execution Context） 的绑定。

先搞懂：为什么线程本地存储（TLS）不行？ #

你想啊，TLS是把数据和线程绑定的，比如你在Thread A上存了一个值，只有Thread A能读到它。但异步场景下，一个请求的异步Action可能先在Thread A执行，await之后切换到Thread B继续，这时候用TLS的话，Thread B读不到Thread A存的HttpContext，反而可能读到另一个请求的数据，完全乱套了。

核心解决方案：异步本地存储 + 执行上下文 #

ASP.NET用的是异步本地存储，它和TLS最大的区别是：它绑定的是异步执行上下文，而不是线程。

• 当CLR执行异步代码遇到await时，会自动捕获当前的执行上下文（包含异步本地存储的数据、安全上下文等），把它和待完成的任务关联起来。
• 当任务完成、异步方法恢复执行时，CLR会把之前捕获的执行上下文还原到当前执行的线程上——不管这个线程是不是之前的那个。
• 这样一来，HttpContext就跟着执行上下文走，不管线程怎么切换，只要是在当前请求的异步调用链里，访问HttpContext时都是从当前执行上下文对应的异步本地存储里取，自然就是当前请求的上下文。

ASP.NET的具体实现细节 #

当一个请求进入ASP.NET管道时：

1. 框架会创建一个专属的HttpContext实例，包含当前请求的所有信息（请求头、响应、Session等）。
2. 把这个HttpContext实例存入异步本地存储的特定槽位里。
3. 在整个请求的生命周期内——包括异步Action的await前后、甚至在注入的服务里访问HttpContext——只要是当前请求的执行上下文，读取HttpContext属性时，都是从这个异步本地存储槽位里获取实例。

另外，你可能用过的IHttpContextAccessor，它的内部实现也依赖这个机制：它就是从异步本地存储里读取当前的HttpContext，所以即使在异步服务方法里，也能拿到正确的请求上下文。

举个简单的场景理解 #

假设你有一个异步Action：

public async Task<IActionResult> MyAsyncAction()
{
    var ctx1 = HttpContext; // 线程A，执行上下文A，存了ctx1
    await SomeLongRunningTask(); // 线程A被回收，任务挂起
    var ctx2 = HttpContext; // 线程B，恢复执行上下文A，取出的还是ctx1
    return Ok(ctx1 == ctx2); // 返回true
}

这里await前后线程变了，但HttpContext还是同一个，因为执行上下文被捕获并还原了，异步本地存储里的HttpContext也跟着过来了。

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