ASP.NET Core中Scoped服务无需IHttpContextAccessor访问HTTP上下文可行吗？

好问题！在ASP.NET Core里，确实有几种不用IHttpContextAccessor的方式来让你的Scoped服务拿到HttpContext——毕竟虽然IHttpContextAccessor方便，但不少开发者会在意它带来的那点额外开销，尤其是高并发场景下。下面给你分享几个实用的方案：

1. 直接传递HttpContext（最直观无开销） #

既然你的服务是Scoped的，生命周期和请求完全一致，那最直接的方式就是在调用服务的地方（比如控制器Action、中间件）把当前的HttpContext直接传进去，不管是作为方法参数，还是在服务初始化时赋值。

举个控制器里的例子：

public class HomeController : ControllerBase
{
    private readonly IMyScopedService _myService;

    public HomeController(IMyScopedService myService)
    {
        _myService = myService;
    }

    public IActionResult Index()
    {
        // 调用服务方法时直接传HttpContext
        _myService.ProcessRequest(HttpContext);
        return Ok();
    }
}

// 你的Scoped服务
public class MyScopedService : IMyScopedService
{
    public void ProcessRequest(HttpContext context)
    {
        // 这里直接使用context就行
        var userId = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    }
}

这种方式完全没有额外开销，逻辑也清晰，适合大多数场景——只要你能在调用服务的地方拿到HttpContext就行。

2. 自定义Scoped上下文持有者（替代IHttpContextAccessor） #

如果你的服务需要在整个生命周期内随时访问HttpContext，不想每次都手动传递，那可以自己实现一个简易版的上下文持有者，原理和IHttpContextAccessor类似，但你能完全控制它的使用范围。

步骤1：创建一个Scoped的持有者类 #

用AsyncLocal<T>来存储HttpContext，保证异步场景下的线程安全（这也是官方IHttpContextAccessor的核心实现方式）：

public class HttpContextHolder
{
    private static readonly AsyncLocal<HttpContext> _asyncContext = new AsyncLocal<HttpContext>();

    public HttpContext CurrentContext
    {
        get => _asyncContext.Value;
        set => _asyncContext.Value = value;
    }
}

步骤2：注册持有者并在中间件中赋值 #

在Program.cs里把持有者注册为Scoped服务：

builder.Services.AddScoped<HttpContextHolder>();

然后在请求管道的中间件里，把当前请求的HttpContext存入持有者：

app.Use(async (context, next) =>
{
    var holder = context.RequestServices.GetRequiredService<HttpContextHolder>();
    holder.CurrentContext = context;
    await next();
});

步骤3：在Scoped服务中依赖注入持有者 #

现在你的服务就能通过持有者拿到HttpContext了：

public class MyScopedService : IMyScopedService
{
    private readonly HttpContextHolder _contextHolder;

    public MyScopedService(HttpContextHolder contextHolder)
    {
        _contextHolder = contextHolder;
    }

    public void DoSomething()
    {
        var context = _contextHolder.CurrentContext;
        // 在这里使用HttpContext做操作
    }
}

这个方案本质上和IHttpContextAccessor功能一致，但你可以根据自己的需求调整它的行为，比如限制某些请求不能存入上下文等。

3. 手动在请求上下文存储服务（适合特殊场景） #

如果你的服务依赖很少，或者你想完全绕过DI的自动注入，可以在中间件里手动创建服务并把它存入HttpContext.Items，之后在需要的地方直接从Items里取。

示例：

// 中间件里创建服务并存储
app.Use(async (context, next) =>
{
    // 手动创建服务，传入当前HttpContext
    var myService = new MyScopedService(context);
    context.Items["MyScopedService"] = myService;
    await next();
});

// 控制器里使用
public IActionResult Index()
{
    var myService = (IMyScopedService)HttpContext.Items["MyScopedService"];
    myService.DoSomething();
    return Ok();
}

不过这个方案需要手动管理服务的创建和依赖解析，比较繁琐，只适合一些特殊场景。

最后得说句实在话：官方的IHttpContextAccessor开销其实非常小，它的核心AsyncLocal<T>是.NET原生的异步上下文传递机制，性能损耗几乎可以忽略不计。除非你在极端高并发的场景下，否则其实不用太纠结它的开销。但如果确实有需求避开它，上面的方案都能满足你的要求。

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