.NET Core：如何在中间件与服务间持久化作用域变量？

一、修复当前Scoped服务注入问题 #

你遇到的核心问题是中间件生命周期与Scoped服务不匹配：中间件默认是Singleton（应用启动时实例化），如果在构造函数中直接注入Scoped服务，会导致服务被强制提升为Singleton，破坏请求级隔离。正确的做法是在InvokeAsync方法中通过当前请求的HttpContext获取Scoped服务实例：

1. 定义LogIdSaver类 #

public class LogIdSaver
{
    public string RequestLogId { get; set; }
}

2. 注册Scoped服务 #

在Program.cs中注册为请求级服务：

builder.Services.AddScoped<LogIdSaver>();

3. 修改LoggingMiddleware实现 #

不在构造函数注入LogIdSaver，而是在请求处理时从当前上下文获取：

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<LoggingMiddleware> _logger;

    public LoggingMiddleware(RequestDelegate next, ILogger<LoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // 获取当前请求的Scoped实例
        var logIdSaver = context.RequestServices.GetRequiredService<LogIdSaver>();
        // 生成唯一日志ID（示例用Guid，也可自定义规则）
        logIdSaver.RequestLogId = Guid.NewGuid().ToString("N");

        // 可选：将日志ID加入日志作用域，让后续所有日志自动携带该ID
        using (_logger.BeginScope(new Dictionary<string, object> { ["RequestLogId"] = logIdSaver.RequestLogId }))
        {
            _logger.LogInformation("开始处理请求，日志ID: {RequestLogId}", logIdSaver.RequestLogId);
            await _next(context);
        }
    }
}

4. 服务中正常注入使用 #

DashboardService直接注入LogIdSaver即可获取当前请求的日志ID：

public class DashboardService
{
    private readonly LogIdSaver _logIdSaver;
    private readonly ILogger<DashboardService> _logger;

    public DashboardService(LogIdSaver logIdSaver, ILogger<DashboardService> logger)
    {
        _logIdSaver = logIdSaver;
        _logger = logger;
    }

    public async Task ProcessData()
    {
        _logger.LogInformation("执行服务逻辑，关联日志ID: {RequestLogId}", _logIdSaver.RequestLogId);
        // 业务代码...
    }
}

二、更优的线程安全方案：使用AsyncLocal #

如果想避免依赖注入容器的开销，AsyncLocal<T>是更轻量的选择——它专门用于跟踪异步上下文的状态，天然支持请求级隔离，线程安全且性能更高：

1. 定义静态日志上下文类 #

public static class LogContext
{
    private static readonly AsyncLocal<string> _requestLogId = new AsyncLocal<string>();

    public static string RequestLogId
    {
        get => _requestLogId.Value;
        set => _requestLogId.Value = value;
    }
}

2. 中间件中设置日志ID #

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<LoggingMiddleware> _logger;

    public LoggingMiddleware(RequestDelegate next, ILogger<LoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var logId = Guid.NewGuid().ToString("N");
        LogContext.RequestLogId = logId;

        using (_logger.BeginScope(new Dictionary<string, object> { ["RequestLogId"] = logId }))
        {
            _logger.LogInformation("开始处理请求，日志ID: {RequestLogId}", logId);
            await _next(context);
        }

        // 可选：请求结束后清空，AsyncLocal会自动在异步上下文结束后回收
        LogContext.RequestLogId = null;
    }
}

3. 服务中直接访问 #

无需注入任何服务，直接通过静态类获取当前请求的日志ID：

public class DashboardService
{
    private readonly ILogger<DashboardService> _logger;

    public DashboardService(ILogger<DashboardService> logger)
    {
        _logger = logger;
    }

    public async Task ProcessData()
    {
        var logId = LogContext.RequestLogId;
        _logger.LogInformation("执行服务逻辑，关联日志ID: {RequestLogId}", logId);
        // 业务代码...
    }
}

方案说明 #

• Scoped服务方案适合依赖注入体系完善的场景，符合.NET Core的DI设计规范；
• AsyncLocal方案更轻量，无需依赖DI容器，适合追求性能或简化代码的场景，且完全线程安全，不会因异步线程切换丢失状态。

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