.NET依赖注入IHttpContextAccessor为null问题排查

你遇到的IHttpContextAccessor为null问题和启动配置无关，完全是代码写法错误导致的，核心问题有两个：

• 错误使用静态成员存储依赖注入的服务：你将_httpContextAccessor定义为静态字段，GetOrganization定义为静态方法，调用时直接通过ShopService.GetOrganization()静态调用，全程没有通过DI容器获取ShopService的实例，ShopService的构造函数根本没有执行，静态字段从未被赋值，自然为null。
  就算某次偶然触发构造函数给静态字段赋了值，静态字段是全局共享的，会被所有并发请求复用，不仅会出现串用户请求数据的安全问题，在应用池回收、非请求场景下还会再次变成null，是依赖注入的典型反模式。
• 异步方法误用.Result阻塞调用：你在调用异步的GetOrganization时用了.Result，这种同步阻塞写法很容易在ASP.NET Core里引发死锁、线程池饥饿问题，哪怕修复了注入问题也会留下严重隐患。

你现有的启动配置完全正确：

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ShopService>();

不需要补充任何额外的服务注册配置。

1. 重构ShopService，去掉所有静态修饰，用实例成员存储依赖、提供方法：

public class ShopService
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    // 构造函数注入，AddHttpContextAccessor注册后该服务一定可以解析到，不需要声明为可空
    public ShopService(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    // 改为实例方法，去掉static
    public async Task<Organization?> GetOrganization(EnvironmentType environment)
    {
        string? accessToken;
        if (_httpContextAccessor.HttpContext != null)
        {
            accessToken = GetToken();
        }
        else
        {
            // 注意非请求上下文（比如后台任务、应用启动阶段）下HttpContext本来就是null，这个判断要保留
            throw new InvalidOperationException("当前不存在活跃请求上下文，无法获取访问令牌");
        }

        // ... 其余原有业务代码
    }
}

2. 在调用GetOrganization的类（如Controller、Razor页面、其他业务服务）中，通过构造函数注入ShopService实例，禁止直接静态调用，同时用await替代.Result做异步调用：

// 调用类的构造函数注入ShopService
private readonly ShopService _shopService;
public YourCallerClass(ShopService shopService)
{
    _shopService = shopService;
}

// 实际调用代码改为异步await
Organization = User?.Identities.FirstOrDefault()?.AuthenticationType switch
{
    "Google" => await _shopService.GetOrganization(EnvironmentType.Google),
    // 其余分支保持原有逻辑即可
};

注意：IHttpContextAccessor仅能在HTTP请求处理生命周期内获取到有效HttpContext，如果你在后台任务、应用启动初始化、单例服务长期持有等非请求场景调用，哪怕注入正常，HttpContext也会为null，属于预期行为。

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