C#怎么使用EF Core拦截器_C#数据库操作拦截器教程【进阶】

关于EF Core拦截器，有不少朋友在实际项目中踩过坑。这篇文章把几个核心要点直接梳理清楚，省去反复调试的时间。

DbCommandInterceptor 怎么注册才生效

拦截器必须在 DbContextOptionsBuilder 配置阶段注册，并且一定要赶在 DbContext 实例创建之前。一个常见的陷阱是：拦截器加在了 OnConfiguring 方法里，结果后面又用 AddDbContext 把配置覆盖了，拦截器自然就丢了。

推荐的做法，是在依赖注入容器注册时统一传入：

services.AddDbContext(options =>{    options.UseSqlServer(connectionString);    options.AddInterceptors(new NoLockCommandInterceptor()); // ✅ 正确：AddInterceptors 在 UseSqlServer 之后});

这里有几个需要注意的点：

• 拦截器类必须继承 DbCommandInterceptor，不能只实现一下接口就完事。
• 如果同时注册了多个拦截器，执行顺序按注册先后排列。不过要注意，EF Core不保证线程安全，所以不要在拦截器里修改共享状态。
• 使用单例实例（比如 static readonly）比每次 new 一个要高效得多，EF Core 是允许复用拦截器实例的。

怎么给 SELECT 自动加 NOLOCK（SQL Server 场景）

这大概是 DbCommandInterceptor 最典型的一个应用场景。不过需要先泼盆冷水：NOLOCK 只对 SQL Server 有效，而且有读脏数据的风险。更重要的是，不能不加区分地乱加，得判断一下命令类型，确认是查询语句才行。

关键操作在于重写 CommandExecuting 方法，然后检查 command.CommandText.StartsWith("SELECT", StringComparison.OrdinalIgnoreCase)：

public override InterceptionResult CommandExecuting(    DbCommand command,    CommandEventData eventData,    InterceptionResult result){    if (command.CommandType == CommandType.Text &&        command.CommandText.TrimStart().StartsWith("SELECT", StringComparison.OrdinalIgnoreCase))    {        command.CommandText = "SELECT * FROM (" + command.CommandText + ") AS t WITH (NOLOCK)";    }    return base.CommandExecuting(command, eventData, result);}

这里有个容易犯的错误：不要直接在原始 SQL 后面拼接 "SELECT ... WITH (NOLOCK)"。因为原始 SQL 里可能含有子查询、CTE 或者注释，简单的字符串替换会直接破坏语法结构。更稳妥的做法是解析一下 SQL，或者只对已知的简单查询生效。

另外，如果项目同时支持 PostgreSQL 或 MySQL，这些数据库是不认 WITH (NOLOCK) 的。所以拦截器里还需要根据 eventData.Connection?.DatabaseProvider 做一下分支处理。

Sa veChangesInterceptor 修改实体前/后怎么取到变更数据

Sa veChangesInterceptor 的 Sa vingChanges 方法可以拿到即将提交的 DbContext 实例。这个时候变更跟踪器（ChangeTracker）已经处于“准备提交”的状态，遍历所有 EntityEntry 是安全的。

典型的审计场景，比如自动填充 CreatedTime 和 ModifiedTime：

public override void Sa vingChanges(DbContextEventData eventData, CancellationToken cancellationToken){    var context = eventData.Context;    if (context == null) return;

var entries = context.ChangeTracker.Entries()
    .Where(e => e.Entity is IAuditable &&
                  (e.State == EntityState.Added || e.State == EntityState.Modified));

foreach (var entry in entries)
{
    var entity = (IAuditable)entry.Entity;
    if (entry.State == EntityState.Added)
        entity.CreatedTime = DateTime.UtcNow;
    entity.ModifiedTime = DateTime.UtcNow;
}

base.Sa vingChanges(eventData, cancellationToken);
}

这里有几个需要注意的地方：

• 千万不要在 Sa vingChanges 里调用 entry.Reload() 或触发新的查询，否则会引起递归或者死锁。
• IAuditable 接口需要自己定义，字段名要和数据库列保持一致，不然 EF 会映射失败。
• 如果实体有导航属性也需要一起审计（比如关联的 User），需要手动遍历 entry.Na vigations，默认情况下是不会递归处理的。

HasQueryFilter 和拦截器共存时为什么 Include 关联数据为空

这个问题其实不是拦截器造成的，而是 HasQueryFilter 的默认行为。EF Core 会对主实体以及它所有 Include 的导航集合都应用同一个过滤器。举个例子，如果 User 设置了软删除过滤，那么 Include(u => u.Orders) 也会被加上 !o.IsDeleted 条件。如果订单表根本没有这个字段，生成的 SQL 要么报错，要么返回空数据。

解决方式不是靠拦截器去改 SQL，而是调整模型配置：

• 对导航目标实体（比如 Order）单独配置 HasQueryFilter，并且条件只作用于该实体自身的字段。
• 用 AsNoTrackingWithIdentityResolution() 绕过跟踪器的过滤逻辑（这只适合只读场景）。
• 改用显式加载：context.Entry(user).Collection(u => u.Orders).Load()，这种方式不走全局过滤器。
• 最干净的方式是移除导航上的级联过滤，改用投影（Select）或原生 SQL 来显式控制关联查询条件。

在这个问题上，拦截器确实帮不上忙——它看到的是最终生成的 SQL，而问题出在 EF Core 查询表达式树的构建阶段，那个时候 SQL 还没生成呢。