dbcommandinterceptor 必须在 dbcontextoptionsbuilder 配置阶段注册，且需早于 dbcontext 实例创建；推荐在 di 容器中通过 adddbcontext 配置时调用 addinterceptors 方法注册，拦截器类须继承 dbcommandinterceptor。
DbCommandInterceptor 怎么注册才生效
拦截器必须在 DbContextOptionsBuilder 配置阶段注册，且需确保注册时机早于 DbContext 实例创建。常见错误是把拦截器加在 OnConfiguring 里但又用 AddDbContext 覆盖了配置，导致拦截器被丢弃。
推荐做法是统一在 DI 容器注册时传入：
services.AddDbContext<appdbcontext>(options =>
{
options.UseSqlServer(connectionString);
options.AddInterceptors(new NoLockCommandInterceptor()); // ✅ 正确：AddInterceptors 在 UseSqlServer 之后
});</appdbcontext>
- 拦截器类必须继承
DbCommandInterceptor，不能只实现接口 - 若同时注册多个拦截器，执行顺序按注册先后，但不保证线程安全，避免在拦截器里改共享状态
- 使用单例实例（如
static readonly）比每次 new 更高效，EF Core 允许复用
怎么给 SELECT 自动加 NOLOCK（SQL Server 场景）
这是最典型的 DbCommandInterceptor 使用场景，但要注意：NOLOCK 只对 SQL Server 有效，且可能读到脏数据。不能无差别加，得判断命令类型和是否为查询。
关键点在于重写 CommandExecuting 方法，并检查 command.CommandText.StartsWith("SELECT", StringComparison.OrdinalIgnoreCase)：
public override InterceptionResult<dbdatareader> CommandExecuting(
DbCommand command,
CommandEventData eventData,
InterceptionResult<dbdatareader> 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);
}</dbdatareader></dbdatareader>
- 不要直接拼接
"SELECT ... WITH (NOLOCK)"，因为原始 SQL 可能含子查询、CTE 或注释，简单替换会破坏语法 - 更稳妥的做法是解析 SQL（用第三方库如
Microsoft.Data.SqlClient的轻量解析器），或仅对已知简单查询生效 - PostgreSQL / MySQL 不支持
WITH (NOLOCK)，拦截器中需根据eventData.Connection?.DatabaseProvider分支处理
SaveChangesInterceptor 修改实体前/后怎么取到变更数据
SaveChangesInterceptor 的 SavingChanges 方法能拿到即将提交的 DbContext 实例，但此时变更跟踪器（ChangeTracker）已处于“准备提交”状态，可安全遍历所有 EntityEntry。
典型审计场景：自动填充 CreatedTime / ModifiedTime：
public override void SavingChanges(DbContextEventData eventData, CancellationToken cancellationToken)
{
var context = eventData.Context;
if (context == null) return;
<pre class="brush:php;toolbar:false;">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.SavingChanges(eventData, cancellationToken);}
- 别在
SavingChanges里调用entry.Reload()或触发新查询，会引发递归或死锁 -
IAuditable接口需自己定义，字段名要和数据库列一致，否则 EF 不会映射 - 若实体有导航属性且也需审计（如关联的 User），需手动遍历
entry.Navigations，默认不递归
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 还没生成。
