N+1查询由未预加载导航属性触发，如循环访问order.Customer.Name时未用Include；解决方式包括用Include/ThenInclude预加载、Select投影避免全量加载，以及禁用延迟加载。
EF Core 中 N+1 查询是怎么被触发的
当你用 IQueryable 查询主表后，在循环里访问导航属性（比如 order.Customer.Name），而这个导航属性没被预先加载，EF Core 就会在每次访问时发起一次新查询——主查 1 次，N 条记录就额外发 N 次，典型 N+1。
常见诱因包括：
• 忘记调用 Include 或 ThenInclude
• 在 Select 投影中引用未加载的导航属性
• 使用异步枚举（await foreach）但没提前展开关系
• 启用了延迟加载（LazyLoadingProxy）且未禁用或谨慎控制
用 Include + ThenInclude 预加载关联数据
这是最直接、可控性最强的解决方式，适用于已知要展示哪些关联字段的场景。注意它生成的是 SQL JOIN，不是子查询，性能通常更稳。
实操要点：
• 多级导航必须用 ThenInclude，不能链式点（Include(x => x.OrderItems.Product) 会报错）
• 避免无意义的全量加载，比如只显示客户名却 Include(x => x.Addresses).Include(x => x.Orders)
• 如果只需要部分字段，优先考虑 Select 投影而非全实体加载
var orders = await context.Orders
.Include(o => o.Customer)
.ThenInclude(c => c.Address)
.Include(o => o.OrderItems)
.ThenInclude(oi => oi.Product)
.ToListAsync();
用 Select 投影避免加载整张实体表
当页面只要几个字段（比如订单号、客户姓名、商品名），用 Select 构造匿名类型或 DTO，EF Core 会生成更轻量的 SQL，自动跳过无关列和导航属性初始化开销。
关键区别：
• Include 返回的是可追踪的实体，适合后续更新
• Select 返回的是不可追踪的数据，内存占用低、序列化快、无变更跟踪负担
• 投影中若引用未 Include 的导航属性，EF Core 6+ 会尝试自动补 JOIN；但 EF Core 5 及更早版本可能静默转为 N+1（务必验证生成 SQL）
var result = await context.Orders
.Select(o => new {
o.OrderId,
CustomerName = o.Customer.Name,
ProductNames = o.OrderItems.Select(oi => oi.Product.Name)
})
.ToListAsync();
警惕 AsNoTracking + 显式加载的组合陷阱
有人以为加了 AsNoTracking() 就能随便访问导航属性，其实不然：如果没 Include 也没开启延迟加载，访问 order.Customer 会返回 null（EF Core 不抛异常），容易引发空引用；若开了延迟加载，又会掉回 N+1。
安全做法：
• 纯读场景优先用 Select 投影 + AsNoTracking()
• 必须用实体时，明确 Include 所有需要的导航，再加 AsNoTracking() 减少变更跟踪开销
• 绝对不要依赖延迟加载处理列表页的关联数据——它无法批量优化，且难以调试
真正难的不是写对 Include，而是判断“这次到底要不要加载这个导航”。业务逻辑越复杂，预加载策略越容易在某个分支漏掉，建议配合 EF Core 日志（LogTo）定期抓出隐式查询。
