EFCore中Include不生效主因是查询链被中断或使用不当：必须在执行方法前调用，避免Select投影、确保导航属性配置正确、ThenInclude路径连续，AsSplitQuery需配合Include且不支持聚合操作，循环内查库才是N+1主因。
EFCore里用Include不生效，查出来还是N+1？
不是Include没写对，就是没意识到它只作用于当前查询的根实体——比如你查Order并Include了Customer，但后续又对Order.Items做了.Select或.Where，EFCore很可能丢弃预加载，回退到懒加载或触发额外查询。
-
Include必须在ToList()、FirstOrDefault()等执行方法前调用，且不能被中间的LINQ操作“打断” - 避免在
Include后接Select投影到匿名类型或DTO：这会让EFCore放弃导航属性的预加载逻辑 - 如果用了
AsNoTracking()，Include仍有效，但关联实体不会被上下文跟踪——这不是N+1问题，但可能让你误以为没加载成功
多层嵌套ThenInclude总报错或加载不全
ThenInclude不是链式调用越长越好，它严格依赖前一个Include的类型推导。常见错误是路径断掉，比如从Order→Customer→Address没问题，但想再ThenInclude到Address.City，就得确认Address确实是导航属性而非普通引用类型。
- 确保每级属性都是导航属性（即配置了
HasOne/HasMany），而不是POCO里的普通string或int - 用
ThenInclude时别混用Lambda和字符串路径：Include(x => x.Customer).ThenInclude(x => x.Address)可以，但Include("Customer").ThenInclude("Address")在EFCore 6+已废弃且易出错 - 如果嵌套层级深（如3级以上），考虑拆成多个
Include调用，比强行用ThenInclude更稳定
用Load或Entry手动加载反而更慢？
显式加载（context.Entry(entity).Collection(e => e.Items).Load()）本质是发新SQL，不是预加载——它解决的是“已有实体后补数据”的场景，不是替代Include的方案。滥用会导致更多往返数据库，把N+1变成M+N+1。
- 只在确实需要延迟加载单个实体的关联数据时用，比如编辑页面先查
Order，用户点开才查Items - 批量手动加载需配合
AsSplitQuery()，否则每个Load()都是一次独立查询，性能雪崩 - 注意
Reference和Collection方法的区别：前者用于一对一/零对一，后者用于一对多；选错会直接抛InvalidOperationException
EFCore 5+的AsSplitQuery真能治N+1？
能，但只对“一对多+多对一混合查询”有效，比如查Order带Customer和Items。它把原SQL拆成多个独立查询，用内存Join合并结果——避免笛卡尔积膨胀，也绕过Include的路径限制。但它不是银弹。
- 必须配合
Include使用：query.Include(x => x.Customer).Include(x => x.Items).AsSplitQuery()，单独AsSplitQuery无意义 - 不支持
Distinct、GroupBy等聚合操作，加了就自动退回到单查询模式 - 网络往返变多，小数据量下可能比单查询慢；大数据量+深度嵌套时才显优势
最常被忽略的一点：N+1往往不是Include写得不对，而是业务代码里在循环里调用context.Find()或FirstAsync()——这种写法连Include的机会都没有。先抓SQL日志看实际发了几条，再决定是改查询还是重构循环逻辑。
