使用SaveChangesInterceptor而非重写OnBefore/AfterSaveChanges的理由有哪些？

首先明确：性能上两者几乎没有差异——因为它们本质上都是EF Core提供的SaveChanges生命周期钩子，底层执行路径大同小异，不会有明显的性能差距。你提到的多上下文共用逻辑确实是核心优势之一，除此之外还有这些关键理由：

• 更细粒度的拦截控制
  SaveChangesInterceptor提供了更细分的生命周期方法，比如针对单个实体的SavingChanges/SavedChanges，以及针对整个SaveChanges流程的SaveChangesStarting/SaveChangesCompleted，甚至可以精准拦截Insert/Update/Delete等具体操作类型。而重写DbContext的OnBeforeSaveChanges只能全局处理所有待变更的实体，没法针对性地做逻辑处理。
  举个例子，要只拦截Product实体的更新操作：

  // 使用Interceptor的方式
  public override ValueTask<InterceptionResult<int>> SavingChangesAsync(DbContextEventData eventData, InterceptionResult<int> result, CancellationToken cancellationToken = default)
  {
      foreach (var entry in eventData.Context.ChangeTracker.Entries<Product>())
      {
          if (entry.State == EntityState.Modified)
          {
              // 仅处理Product的更新逻辑
          }
      }
      return base.SavingChangesAsync(eventData, result, cancellationToken);
  }
  

  而如果用重写OnBeforeSaveChanges，你需要遍历所有实体类型再筛选，代码冗余度更高。

• 关注点分离，代码更整洁
  Interceptor是独立的类，专门负责拦截逻辑，不用把这些额外代码塞进DbContext里。DbContext的核心职责是实体映射、数据库配置，把拦截、审计、日志这类横切逻辑抽离出去，更符合单一职责原则，代码维护起来更轻松。

• 动态控制逻辑的启用/禁用
  你可以在运行时通过DI容器动态添加或移除Interceptor，比如在开发环境启用审计拦截，生产环境关闭；或者根据业务开关临时禁用某个逻辑。而重写DbContext的方法是硬编码在类中的，要调整只能修改代码重新编译。

• 依赖注入更灵活
  Interceptor可以直接通过构造函数注入其他服务（比如日志组件、缓存服务），而且多个上下文共用同一个Interceptor时，不用重复处理注入逻辑。虽然DbContext也支持DI，但每个上下文都要单独配置相关依赖，复用性不如Interceptor。

• 兼容更多EF Core高级场景
  在一些复杂场景下，比如事务嵌套、批量操作，Interceptor能拿到更丰富的上下文信息（比如当前事务状态、变更操作的详细元数据），而重写DbContext的方法参数有限，很难获取这些细节。

总结一下：如果你的需求只是简单的全局前置/后置处理，重写DbContext方法足够用；但如果需要更灵活的控制、复用逻辑、关注点分离，SaveChangesInterceptor是更优的选择。

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