HttpContext.Current：异步模式下的疑似陷阱之源

最近园子里首页有好几篇文章都是讲异步编程的，尤其是几篇讲博客园自身的异步化建设的文章，看了以后很有收获。
 
闲暇之余再重新查查资料温故知新学习一遍，重新认识了SynchronizationContext、AspNetSynchronizationContext和ConfigureAwait。
 
最大的心得是，web异步化处理后，容易引发问题的一个重要方面就是请求上下文，也就是本文标题里的HttpContext.Current。
 
园子里fish-li写过一篇HttpContext.Current并不是无处不在，写的比较详细深入，看过这篇文章你就会非常明确用了HttpContext.Current容易引发哪些问题了。
 
记得很早以前开发某项目，引入了一个外部日志组件，反汇编之后竟然发现有直接通过HttpContext.Current获取IP、UserAgent、请求参数等信息的，当时就对同事说千万不要在异步逻辑里调用这个组件里的任何记录日志的方法，防止触雷。
 
我的观点是，不要轻易在任何地方（类库）使用HttpContext.Current，因为它并非无处不在，尽量把HttpContext的当前请求对象保留起来，可以传参或者供外部类库回调时重新获取请求上下文使用。
 
但是，很多类库（包括MS自己的）的现有内部实现中都离不开HttpContext.Current，我这里并不是说类库中充斥着HttpContext.Current就是一种bad design。根据我个人的分析，至少目前已被广泛使用的FormsAutentication内部实现，满满的都是HttpContext.Current充斥其中，而且最核心的读写cookie的方法都依赖HttpContext.Current。如果完全适应各种异步场景，说不定也会碰到HttpContext.Current不灵的情况，目测还有可优化的空间^_^。
 

我们所熟悉的aspx,ascx,ashx,masterpage,MvcHandler,MvcRouteHandler和MvcHttpHandler等等，每一个类实现的背后都有Httpcontext的存在，是否也有HttpContext.Current这种暴力写法？据我所知，反正Page类是有的。好奇查看了一下MVC3的源码，搜索关键字“HttpContext.Current”，整个MVC3源码匹配的行数为12行，MvcHandler和MvcHttpHandler确实有HttpContext.Current的出现，它最终作为ProcessRequest或BeginProcessRequest方法的内部逻辑的一部分或者当中的参数，我们还是能够理解的。

本文来自http://www.1314721.com.cn/