Entity Framework连接池：如何将UserId注入SQL Server的session_context？

你的核心痛点是在连接池复用的场景下，确保每个数据库操作（不管是查询还是写入）都能获取到当前正确的UserId，而当前仅在SaveChanges()中设置的方式会遗漏查询场景的处理（比如LINQ查询时，连接可能是从池里复用的，此时session_context还是之前用户的ID）。

为什么选择拦截器？ #

EF6的DbConnectionInterceptor是官方提供的扩展点，能拦截连接的打开/关闭等事件。利用它可以在每次连接被使用（无论是新创建还是从连接池复用）时自动设置session_context，确保所有数据库操作（查询、写入、存储过程调用）都能拿到正确的UserId，同时完全兼容连接池。

具体实现步骤 #

1. 创建连接拦截器类

这个类会在连接打开时自动执行SetUserId存储过程：

using System.Data.Entity.Infrastructure.Interception;
using System.Data.Db;
using System.Web;
using System.Threading.Tasks;
using System.Threading;

public class UserIdSessionContextInterceptor : DbConnectionInterceptor
{
    // 拦截同步连接打开事件
    public override void Opened(DbConnection connection, DbConnectionInterceptionContext interceptionContext)
    {
        base.Opened(connection, interceptionContext);
        SetUserIdOnConnection(connection);
    }

    // 拦截异步连接打开事件（处理异步数据库操作）
    public override async Task OpenedAsync(DbConnection connection, DbConnectionInterceptionContext interceptionContext, CancellationToken cancellationToken)
    {
        await base.OpenedAsync(connection, interceptionContext, cancellationToken);
        await SetUserIdOnConnectionAsync(connection, cancellationToken);
    }

    // 同步设置UserId到session_context
    private void SetUserIdOnConnection(DbConnection connection)
    {
        var userId = GetCurrentUserId() ?? -1; // 未知用户返回-1

        using (var cmd = connection.CreateCommand())
        {
            cmd.CommandText = "SetUserId";
            cmd.CommandType = System.Data.CommandType.StoredProcedure;
            
            var userIdParam = cmd.CreateParameter();
            userIdParam.ParameterName = "@userId";
            userIdParam.Value = userId;
            
            cmd.Parameters.Add(userIdParam);
            cmd.ExecuteNonQuery();
        }
    }

    // 异步设置UserId到session_context
    private async Task SetUserIdOnConnectionAsync(DbConnection connection, CancellationToken cancellationToken)
    {
        var userId = GetCurrentUserId() ?? -1;

        using (var cmd = connection.CreateCommand())
        {
            cmd.CommandText = "SetUserId";
            cmd.CommandType = System.Data.CommandType.StoredProcedure;
            
            var userIdParam = cmd.CreateParameter();
            userIdParam.ParameterName = "@userId";
            userIdParam.Value = userId;
            
            cmd.Parameters.Add(userIdParam);
            await cmd.ExecuteNonQueryAsync(cancellationToken);
        }
    }

    // 替换成你获取当前登录用户ID的逻辑
    private int? GetCurrentUserId()
    {
        if (HttpContext.Current?.User?.Identity.IsAuthenticated ?? false)
        {
            // 示例：从Claims身份中获取UserId
            var claimsIdentity = HttpContext.Current.User.Identity as System.Security.Claims.ClaimsIdentity;
            var userIdClaim = claimsIdentity?.FindFirst(System.Security.Claims.ClaimTypes.NameIdentifier);
            
            if (userIdClaim != null && int.TryParse(userIdClaim.Value, out int userId))
            {
                return userId;
            }
        }

        // 非Web场景（比如后台任务）可以在这里返回系统用户ID
        return null;
    }
}

2. 全局注册拦截器

在应用启动时注册这个拦截器（比如Global.asax的Application_Start方法）：

protected void Application_Start()
{
    // 注册拦截器，全局生效
    DbInterception.Add(new UserIdSessionContextInterceptor());
    
    // 其他初始化代码...
}

方案优势对比 #

和你当前的SaveChanges()重写方案相比，这个方案有几个关键优势：

• 覆盖所有数据库操作：不仅是写入（SaveChanges），查询、存储过程调用等所有数据库操作都会使用正确的UserId，避免了查询时用户ID串用的问题。
• 自动处理连接池：每次从连接池复用连接时，都会重新设置UserId，彻底解决连接池带来的状态残留问题。
• 异步支持：处理了异步数据库操作（比如SaveChangesAsync、ToListAsync），确保异步场景下也能正确设置。
• 无侵入性：不需要修改每个DbContext的方法，一次注册全局生效。

额外注意事项 #

• 非Web场景处理：如果你的应用包含后台任务（比如定时作业），这些场景没有HttpContext，需要在GetCurrentUserId()中返回对应的系统用户ID（比如0），避免审计日志出现大量-1的未知用户。
• 性能影响：每次连接打开时执行一次存储过程，开销极小，完全可以忽略。
• session_context的生命周期：session_context和数据库连接绑定，当连接被放回池时，状态会保留，但下一次使用时会被覆盖，因此不需要额外清理。

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