查询未跟踪模型列表致元素被跟踪，引发EF实体附加主键冲突错误

嘿，这个问题我太熟悉了，咱们一步步来拆解清楚：

为什么Bar实例会被提前跟踪？ #

EF Core的DbContext本质上是一个实体跟踪器——默认情况下，所有从数据库查询出来的实体（不管是直接查Bar，还是通过其他实体的导航属性加载的Bar）都会被上下文自动跟踪，除非你在查询时显式加上AsNoTracking()。

你疑惑的“查询未跟踪模型中的列表会导致列表元素被跟踪”，完全是导致这个错误的核心原因！举个常见的场景：

你查询一个主实体（比如Foo）时用了AsNoTracking()，但后续通过context.Entry(fooEntity).Collection(f => f.Bars).Load()来加载关联的Bar列表。这时候加载的Bar就会被上下文跟踪，因为这个操作是直接通过DbContext的Entry API触发的，EF会自动跟踪这些加载的实体。

只要你的DbContext实例里已经存在一个被跟踪的同IDBar，当你再尝试把另一个同ID的Bar实例附加并设为Modified时，就会触发那个主键冲突的错误——EF不允许同一个上下文跟踪两个同主键的实体。

怎么解决这个问题？ #

给你几个实用的解决方案：

• 优先更新已跟踪的实体：在附加新实例前，先检查上下文是否已经跟踪了目标ID的Bar：

  var existingBar = context.ChangeTracker.Entries<Bar>()
      .FirstOrDefault(e => e.Entity.Id == yourBar.Id)?.Entity;
  if (existingBar != null)
  {
      // 直接更新已跟踪实体的属性
      context.Entry(existingBar).CurrentValues.SetValues(yourBar);
  }
  else
  {
      // 没有被跟踪的话，再附加并设为Modified
      context.Bars.Attach(yourBar);
      context.Entry(yourBar).State = EntityState.Modified;
  }
  

• 解除已跟踪实体的跟踪：如果你确实需要用新的实例来更新，可以先把已跟踪的同ID实体从上下文分离：

  var trackedEntry = context.ChangeTracker.Entries<Bar>()
      .FirstOrDefault(e => e.Entity.Id == yourBar.Id);
  if (trackedEntry != null)
  {
      trackedEntry.State = EntityState.Detached;
  }
  // 现在可以安全附加新实例了
  context.Bars.Attach(yourBar);
  context.Entry(yourBar).State = EntityState.Modified;
  

• 严格控制查询的跟踪状态：所有不需要后续更新的查询，都加上AsNoTracking()，包括关联实体的查询。比如：

  var foo = context.Foos.AsNoTracking()
      .Include(f => f.Bars)
      .FirstOrDefault(f => f.Id == fooId);
  

  这样加载的Bars列表里的实体也会是未跟踪状态，不会干扰后续的附加操作。

• 考虑使用短生命周期的DbContext：如果你的业务流程中，查询和更新是两个独立的步骤，可以用不同的DbContext实例来处理——查询用一个上下文，更新用另一个，这样就不会出现跨步骤的跟踪冲突。

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