MVC5多数据库场景下，在Application_BeginRequest注册全局过滤器是否安全？

我来帮你梳理下这个问题——你遇到的NullReferenceException确实和在Application_BeginRequest注册过滤器有关，而且这个做法本身就不符合MVC的设计规范，咱们一步步来解决：

为什么在Application_BeginRequest注册过滤器不安全 #

MVC的全局过滤器集合是设计为在应用启动阶段（Application_Start）完成注册的，这是一个单例初始化阶段，所有过滤器会被一次性加载并稳定下来，后续请求只会复用这些已注册的实例。

你虽然加了FiltersConfigured的判断，但仍可能触发异常：

• 并发场景下，多个请求同时进入Application_BeginRequest，可能导致过滤器集合被重复修改或处于不一致状态；
• MVC内部的FilterProviderCollection.RemoveDuplicates方法预期集合是启动时就完成构建的，动态修改会打破这个假设，进而出现空引用（比如集合内元素未完全初始化就被处理）。

所以结论是：绝对不要在Application_BeginRequest注册全局过滤器，这会带来不可预测的稳定性问题。

更好的多数据库连接字符串处理+过滤器实现方案 #

核心思路是延迟获取连接字符串和服务实例，把过滤器注册移回Application_Start，同时解决多数据库的动态连接问题。这里提供两种可行方案：

方案一：引入依赖注入（DI，推荐）

如果你的项目还没用到DI，建议引入轻量容器（比如Autofac、Unity，或者ASP.NET自带的DependencyResolver），让容器负责动态生成带对应连接字符串的服务实例。

步骤示例（以Autofac为例）：

1. 配置DI容器，根据当前请求域名动态生成服务：

// 在容器初始化代码中
builder.Register(c => {
    // 从当前请求的URL解析连接字符串
    var httpContext = c.Resolve<IHttpContextAccessor>().HttpContext;
    var connectionString = GetConnectionStringFromDomain(httpContext.Request.Url);
    return new UserService(connectionString);
}).As<IUserService>().InstancePerRequest(); // 每个请求生成一个实例

builder.Register(c => {
    var httpContext = c.Resolve<IHttpContextAccessor>().HttpContext;
    var connectionString = GetConnectionStringFromDomain(httpContext.Request.Url);
    return new FeatureService(connectionString);
}).As<IFeatureService>().InstancePerRequest();

// 让Autofac接管MVC过滤器的依赖注入
builder.RegisterFilterProvider();

2. 修改过滤器，通过构造函数注入服务接口：

public class PermissionsFilterAttribute : ActionFilterAttribute {
    private readonly IUserService _userService;

    // 由DI容器自动注入实例
    public PermissionsFilterAttribute(IUserService userService) {
        _userService = userService;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        // 直接使用_userService处理权限逻辑
        base.OnActionExecuting(filterContext);
    }
}

3. 在Application_Start正常注册过滤器：

public static void RegisterGlobalFilters(GlobalFilterCollection filters) { 
    filters.Add(new HandleErrorAttribute(), 1); 
    filters.Add(new PermissionsFilterAttribute(), 2); 
    filters.Add(new AppFeaturesFilterAttribute()); 
}

方案二：延迟获取服务（不使用DI的轻量方案）

如果暂时不想引入DI，可以让过滤器在请求执行阶段才动态获取连接字符串和服务实例，而不是在构造时传入：

1. 修改过滤器类，在OnActionExecuting中初始化服务：

public class PermissionsFilterAttribute : ActionFilterAttribute {
    public override void OnActionExecuting(ActionExecutingContext filterContext) {
        // 从当前请求的URL解析连接字符串
        var connectionString = GetConnectionStringFromDomain(filterContext.HttpContext.Request.Url);
        var userService = new UserService(connectionString);
        
        // 这里执行权限验证逻辑
        base.OnActionExecuting(filterContext);
    }
}

// 同理修改AppFeaturesFilterAttribute，在OnActionExecuting中创建FeatureService

2. 回到Application_Start注册过滤器：

public static void RegisterGlobalFilters(GlobalFilterCollection filters) { 
    filters.Add(new HandleErrorAttribute(), 1); 
    filters.Add(new PermissionsFilterAttribute(), 2); 
    filters.Add(new AppFeaturesFilterAttribute()); 
}

这种方式的好处是，过滤器在启动阶段就完成注册，不会触发MVC内部的集合异常，同时每个请求都会动态获取对应域名的连接字符串，完美适配多数据库场景。

额外优化建议 #

• 对解析后的连接字符串做缓存（比如按域名缓存），避免每次请求都重复解析URL；
• 全局过滤器默认是单例的，所以绝对不要在过滤器构造函数中处理请求级别的逻辑（比如获取Request.Url），这会导致数据混乱。

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