ASP.NET MVC应用Request对象属性间歇性为空，引发空引用异常求助

这种随机出现的空引用真的太闹心了！尤其是之前跑了3个月都稳稳的，突然就掉链子，完全摸不着头脑对吧？结合你描述的场景，我整理了几个实战中大概率能解决问题的排查方向，你可以挨个试：

很多时候这种随机空引用都是因为在非请求上下文线程里访问Request导致的——比如用Task.Run开后台线程，或者在异步方法里没正确捕获上下文，此时请求可能已经被IIS回收了，Request自然就成了null。

• 先检查代码里有没有类似这样的危险写法：

  Task.Run(() => {
      var headerValue = Request.Headers["X-Custom-Header"]; // 这里很容易踩坑！
  });
  

• 解决办法：如果必须在异步操作里用请求相关数据，提前把需要的字段复制出来，再传到异步逻辑里，比如：

  // 先在请求上下文里把需要的数据拿出来
  var targetHeader = Request.Headers["X-Custom-Header"];
  Task.Run(() => {
      // 用复制好的targetHeader，别直接碰Request
      ProcessHeader(targetHeader);
  });
  

3天前突然出问题，大概率是应用池的配置被改动了（比如运维调整了回收策略），或者回收过程中出现了上下文异常。

• 先去IIS里看应用池的回收设置：是不是开了固定时间回收、内存/CPU阈值回收？回收过程中如果刚好有请求在处理，很可能会导致Request上下文直接丢失。
• 试试手动回收一次应用池，然后观察问题是否还出现；另外可以开启应用池的快速失败保护日志，看看有没有异常进程被终止的记录。
• 检查应用池的托管管道模式：如果最近被改成了经典模式，换回集成模式试试——MVC应用在集成模式下的上下文管理更稳定。

最近有没有新增/更新过NuGet包？或者运维在IIS上装了新的HTTP模块（比如日志、安全类的）？有些第三方模块会在请求处理流程中意外篡改或释放请求上下文。

• 先暂时禁用最近新增的HTTP模块（在IIS站点的“模块”设置里），或者回滚最近更新的NuGet包，看看问题会不会消失。
• 打开web.config，找到<modules>节点，把最近加的模块注释掉，重启站点试试。

如果用户的请求在处理过程中突然中断（比如用户关了浏览器、网络波动），IIS会提前回收请求上下文，此时你的代码再访问Request就会抛出空引用。

• 先做个临时补救：在所有访问Request的地方加空值检查，避免直接崩溃：

  if (Request != null) {
      var requestHeaders = Request.Headers;
      // 后续业务逻辑
  }
  

• 再深挖根源：检查代码里有没有在请求生命周期后期（比如Application_EndRequest之后）还访问Request的逻辑，或者用了async void的方法——这类方法很容易导致请求上下文失控。

既然运维已经给了日志，不如再挖深一点：

• 开启IIS的失败请求跟踪（FRT），设置跟踪空引用异常的规则，这样能抓到异常发生时的完整请求流程，包括哪个模块、哪行代码出的问题。
• 如果问题能稳定复现，生成应用程序的崩溃转储文件，用Visual Studio或者WinDbg分析，直接定位到Request为null的具体原因——这是最精准的排查方式。

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