ASP.NET Core 控制器依赖注入获取HttpContext.Session的方法与最佳实践

之前的所有报错，本质都是对ASP.NET Core的Session生命周期、依赖注入匹配逻辑的理解偏差导致的：

• ISession不是可以独立创建的服务，它是完全依附于当前请求HttpContext的从属属性，没有无参构造函数、也没有对应的工厂逻辑能让DI容器独立创建它的实例，直接写services.AddScoped<ISession>()自然会在服务解析阶段直接抛错
• 之前写的控制器代码本身存在基础的类型错误：把私有字段拼写为HttpContect，把HttpContext类型的变量当成Session容器调用不存在的.session属性，本身就无法通过编译
• 尝试用IHttpContextAccessor实现逻辑时报错，基本逃不出两个原因：要么没有注册对应的服务，要么中间件管道的配置顺序错了，导致请求到达控制器时，HttpContext上还没有挂载Session信息

• 第一步：在Startup的服务注册阶段完成基础配置
  不要手动注册ISession，直接调用框架提供的Session扩展方法：
  services.AddSession();
  如果是使用.NET Core 3.0之前的老版本，需要额外手动加上一行：
  services.AddHttpContextAccessor();
  （3.0及以上版本的AddSession方法会自动完成IHttpContextAccessor的注册，不需要额外写）
• 第二步：配置请求管道的中间件顺序
  在Startup的Configure方法里，必须把app.UseSession()放在路由、控制器请求处理逻辑之前，推荐顺序是路由映射 → 会话初始化 → 控制器映射，也就是要保证UseSession()的位置在app.MapControllerRoute()之前，不然Session逻辑还没执行，HttpContext上根本不会挂载Session对象
• 第三步：控制器里的正确依赖注入写法
  注意不要直接把ISession当注入参数，要注入IHttpContextAccessor来间接获取当前请求的上下文和Session：

  public class AccountController : Controller
  {
      private readonly IHttpContextAccessor _httpContextAccessor;
  
      // 构造函数注入，类型不要写错
      public AccountController(IHttpContextAccessor httpContextAccessor)
      {
          _httpContextAccessor = httpContextAccessor;
      }
  
      // 在任意Action中获取Session的逻辑
      public IActionResult TestSession()
      {
          // 先判断上下文是否存在，避免非请求场景报空引用
          var session = _httpContextAccessor.HttpContext?.Session;
          // 后续Session读写逻辑
          return Ok();
      }
  }
  

• 手动把ISession直接注册到DI容器的做法完全没有合理性：本质违背了ISession的生命周期设计——ISession的存在完全绑定单次HTTP请求，没有独立的实例能力，这种注册方式根本无法产出可用的ISession实例，框架也从未支持直接解析ISession的逻辑
• 通过注入IHttpContextAccessor间接获取当前请求Session的方式，是框架官方推荐的合规实现，但也要结合场景判断是否有必要：
  • 如果只是在控制器Action内部使用Session，完全不需要额外注入，直接用Controller基类自带的HttpContext.Session属性就能正常访问，写法更简洁，也不会引入额外构造函数依赖
  • 如果是在控制器之外的服务层、类库逻辑中需要访问Session，这种注入方式是行业通用标准做法，只要做好空值判断（比如后台任务、定时任务这类非请求场景下，HttpContext为null，直接取Session会触发空引用），就不存在设计层面的问题

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