ASP.NET MVC中TempData首次重定向为空 本地正常服务器运行异常

• 本地开发环境TempData读写完全正常，部署到服务器后出现首次重定向读不到存储值、需要多次刷新/多次重定向才能获取内容的延迟生效问题
• 对应代码场景：Verify动作写入TempData["VerifyInfo"]/TempData["Error"]后重定向到VerifyPaymentView，首次进入视图时对应TempData值为空，二次请求才可正常读取

ASP.NET MVC的TempData默认基于内存Session实现，其读写规则为单次请求有效：请求开始时从Session加载全部TempData值，被读取过的key会在请求结束时被自动清除，仅未被读取、或显式标记保留的key会留存到下一次请求。本地环境与服务器环境的存储逻辑差异，是导致该异常的核心原因，常见触发场景包括：

• 服务器多进程/多实例部署时未配置粘滞会话，且使用默认内存Session做存储：比如应用池配置了多个工作进程、前端做了负载均衡，写入TempData的请求被路由到A进程/实例，后续读取TempData的请求被路由到B进程/实例，因两个进程/实例的内存Session相互独立，首次读取时B端没有对应值，二次请求刚好路由回A端时才会读到数据
• IIS应用池配置了闲置超时回收、定时固定回收：应用进程回收后内存中存储的Session、TempData数据会被全部清空，首次请求触发回收时，之前写入的TempData随进程丢失，等应用重启完成后新写入的TempData才会被正常读取
• SessionID Cookie配置不匹配：应用部署在IIS虚拟目录下时，默认生成的SessionCookie路径为站点根目录，无法随虚拟目录下的请求正确回传，导致首次请求使用全新的SessionID，读不到之前绑定在旧SessionID上的TempData，二次请求Cookie正常回传后才会匹配到对应Session
• 代码逻辑打乱TempData生命周期：读取TempData后又重新给对应key赋值，会导致本来应该单次清除的值被留存到后续请求，出现延迟生效的视觉错觉

• 分布式环境下替换默认的内存Session存储为共享式Session（如Redis、SQL Server存储），同时配置IIS粘滞会话，保证所有请求的Session、TempData数据一致
• 调整IIS应用池配置：关闭闲置超时回收，将定时回收时间调整为业务低峰时段，避免进程回收导致内存数据丢失
• 显式配置SessionCookie的参数：将Cookie路径设置为当前应用的根路径，HTTPS场景下配置合理的SameSite、Secure属性，避免Cookie被浏览器拦截导致SessionID无法回传
• 修正现有代码中不符合TempData生命周期的逻辑：读取到TempData值后将内容传递给视图，不需要重新赋值回TempData，避免打乱自动清除规则，参考修正后的代码：

  public ActionResult VerifyPaymentView()
  {
      var userId = User.GetUserId();
      var isLogin = User.Identity.IsAuthenticated;
  
      if (TempData["Error"] != null)
      {
          ViewBag.IsError = true;
          return View();
      }
  
      if (TempData["VerifyInfo"] != null)
      {
          var verifyInfo = (VerifyInfo)TempData["VerifyInfo"];
          return View(verifyInfo);
      }
      return View();
  }
  

  同时避免在全局过滤器、日志逻辑中提前读取TempData，防止未到视图层时TempData的key就被标记为已清除。

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