如何在使用Entity Framework Core包含导航属性时避免Self Referencing Loops

• 优先使用投影映射生成专用传输对象（DTO），这是性能最优的根因解决方案
  核心逻辑是完全切断实体和序列化输出的直接绑定，查询阶段就通过Select把需要的字段映射到不带双向导航属性的DTO上，从生成数据的第一步就不存在循环引用的可能，序列化过程完全不需要执行循环检测逻辑。
  示例代码：

  // 无循环的DTO定义
  public class UserDto
  {
      public int Id { get; set; }
      public string UserName { get; set; }
      public List<PetDto> Pets { get; set; }
  }
  public class PetDto
  {
      public int Id { get; set; }
      public string PetName { get; set; }
      public string Species { get; set; }
  }
  
  // 查询时直接投影，不需要手动处理引用
  var result = await _db.Users
      .AsNoTracking()
      .Select(u => new UserDto
      {
          Id = u.Id,
          UserName = u.UserName,
          Pets = u.Pets.Select(p => new PetDto
          {
              Id = p.Id,
              PetName = p.PetName,
              Species = p.Species
          }).ToList()
      })
      .ToListAsync();
  

  这种方案在大集合场景下的性能优势最明显：不仅避免了序列化阶段的循环检测开销，还能减少数据库侧的多余字段拉取、降低内存占用，比直接返回全量实体再靠序列化器过滤的效率高数倍。

• 如果必须直接返回实体类型，在数据材料化后手动断开反向导航引用
  这种场景下不要等序列化器去识别循环，要在EF把实体从数据库加载完成后、传入序列化逻辑之前，直接把会造成循环的反向引用置空。比如加载完带Pets集合的User实体后，遍历每个Pet实例，把pet.User = null。
  注意操作时要使用AsNoTracking()查询得到的无跟踪实体做处理，不要对EF变更跟踪器里的跟踪实体修改导航属性，否则可能触发不必要的实体状态变更，在后续保存操作时产生误更新。
  这种方式的本质是把循环检测的开销从复杂度较高的序列化栈校验，降到一次线性遍历的置空操作，性能提升非常明显。

• 从EF实体配置层面阻断反向导航属性的自动绑定
  不要在实体关系配置中默认启用双向导航的自动回填，通过明确的关系定义控制导航属性的加载边界。比如配置User和Pet的一对多关系时，只声明外键关联规则，不强制让EF在加载Pets集合时自动回填Pet实体上的User导航属性对象：

  // EF Core关系配置示例
  modelBuilder.Entity<User>()
      .HasMany(u => u.Pets)
      .WithOne(p => p.User)
      .HasForeignKey(p => p.UserId);
  

  这种方式可以从查询执行阶段就避免冗余的对象引用构建，减少不必要的内存对象分配。

关于现有序列化方案的性能损耗说明：
你提到的SelfReferencingLoopHandling.Ignore在大集合下性能差的核心原因，是序列化器需要沿着整个对象图逐节点遍历，每访问一个对象就要检查当前引用栈中是否已经存在该对象，大集合下栈校验的开销会随数据量上升呈线性增长；而PreserveReferencesHandling.Objects虽然能通过特殊标记保留对象关联、避免循环，但生成的JSON会嵌入大量$id/$ref格式的元数据，完全破坏原有业务结构，前端解析时还需要额外实现引用还原逻辑，和直接输出可用业务结构的目标背道而驰。

内容的提问来源于stack exchange，提问作者Bence Mányoki