EF Core单元测试内存数据库场景AsNoTracking失效引发跟踪冲突

• 核心跟踪冲突的来源根本不是业务方法里的历史数据查询逻辑，而是测试准备阶段的种子数据残留跟踪状态
  你的测试基类在AddToInMemoryContext方法中，是直接调用同一个InMemoryContext实例的Add方法加载种子数据的：Add操作本身会将传入的实体纳入上下文跟踪器的管辖范围，哪怕后续执行了SaveChanges将数据持久化到内存数据库，这些实体依然会保持被跟踪状态，不会随保存操作自动脱离跟踪。
• 为什么显式调用的AsNoTracking没有解决问题
  你在业务方法中对历史状态查询加的AsNoTracking，仅作用于本次查询返回的实体对象，完全不会修改上下文跟踪器中已经存在的、同主键实体的跟踪状态。此时上下文跟踪器里早就存了一个你在测试准备阶段加进去的、主键和newProjektStatus完全相同的PPMProjektStatus被跟踪实例，当业务方法调用AddOrUpdate(projektStatus)尝试附加传入的新实体时，就会直接触发同主键跟踪冲突。
• 为什么修改历史数据查询逻辑完全没用
  跟踪状态的残留是测试基类的上下文实例全局持有的，和业务方法里怎么查历史数据没有关系：哪怕你完全删掉历史状态的查询逻辑，只要上下文跟踪器里还留着之前加进去的同主键被跟踪实体，调用AddOrUpdate依然会抛出完全相同的异常。这也是你之前尝试“只取历史状态字段、不查询完整实体”仍然报错的核心原因。
• 为什么生产环境从未出现这个问题
  生产环境的DbContext是标准的请求级生命周期：每个业务请求会创建全新的上下文实例，请求结束直接Dispose销毁上下文。初始化种子数据的操作是在独立的上下文实例中完成的，和执行业务逻辑的上下文完全隔离，根本不会出现种子数据残留到业务上下文跟踪器的情况，因此不会触发冲突。

• 方案1：种子数据加载完成后，主动清空上下文跟踪器
  这是最适配当前测试架构的零侵入修复方式，在AddToInMemoryContext方法执行完SaveChanges后，将跟踪器中所有实体的状态切换为Detached，示例代码：

  protected int AddToInMemoryContext<TEntity>(ICollection<TEntity> entities) where TEntity : BaseEntity
  {
      foreach (var entity in entities)
      {
          this.InMemoryContext.Add(entity);
      }
      var saveResult = this.InMemoryContext.SaveChangesAsync().Result;
      
      // 清空所有跟踪状态，避免种子数据残留导致后续跟踪冲突
      if (this.InMemoryContext is DbContext efContext)
      {
          foreach (var trackedEntry in efContext.ChangeTracker.Entries())
          {
              trackedEntry.State = EntityState.Detached;
          }
      }
      return saveResult;
  }
  

• 方案2：拆分测试上下文的生命周期，对齐生产环境逻辑
  将种子数据加载的逻辑和业务逻辑执行的上下文完全拆分：
  1. 用一个独立的临时上下文实例加载所有测试需要的种子数据，加载完成后直接Dispose临时上下文
  2. 创建一个全新的上下文实例，注入到被测试的业务对象中执行业务逻辑
     这种方式完全复刻生产环境的上下文生命周期，从根源上避免不同阶段的操作共用同一个跟踪器。
• 方案3：排查自定义AddOrUpdate方法的实现
  如果你的自定义AddOrUpdate是通过“先查询同主键实体，再根据查询结果决定新增/更新状态”的逻辑实现的，需要确保这个查询本身加了AsNoTracking，避免查询过程中又把同主键实体纳入跟踪范围。

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