最直接有效的办法是用 Include 显式预加载关联数据，把原本 1+N 次查询压成 1 次 JOIN 查询。别依赖延迟加载，尤其在循环里访问导航属性时，N+1 就悄悄发生了。
用 Include + ThenInclude 一次性加载多级关系
适用于需要完整对象图的场景，比如查博客、文章、作者、评论四级数据：
一级包含：`.Include(b => b.Posts)` 加载所有文章 二级延伸：`.ThenInclude(p => p.Author)` 加载每篇文章的作者 三级延伸：`.ThenInclude(a => a.Profile)` 再加载作者档案（支持链式调用）EF Core 会生成一条含多个 JOIN 的 SQL，避免逐条查询。注意：导航路径必须连续，不能跳级（如不能从 Blog 直接 ThenInclude 到 Comment）。
拆分查询 + 内存关联（Split Queries）
当多级 Include 导致笛卡尔爆炸（比如 1 个订单 × 10 商品 × 5 日志 = 50 行重复数据），可改用独立查询：
EF Core 5+ 支持 `.AsSplitQuery()`，让每个 Include 变成单独 SQL，再由 EF 在内存中按主键/外键自动关联 比单条 JOIN 更省内存和网络带宽，适合子集合数据量大的情况 写法示例：.AsSplitQuery().Include(o => o.Items).ThenInclude(i => i.Logs)
用 Select 投影最小化数据（推荐高频只读接口）
根本不需要整个实体？那就别加载实体，直接取字段：
用.Select()构造匿名类型或 DTO，只查真正要展示的字段 搭配
.AsNoTracking()关闭变更跟踪，查询速度更快、内存更轻 例如：
context.Blogs.Select(b => new { b.Name, PostCount = b.Posts.Count() })
这种方式既避开 N+1，又避免了 Include 带来的冗余数据和笛卡尔膨胀。
关掉延迟加载，杜绝隐式触发
延迟加载（Lazy Loading）是 N+1 的温床，尤其在序列化或日志打印时容易意外触发：
不引用Microsoft.EntityFrameworkCore.Proxies包 或显式禁用：
options.UseLazyLoadingProxies(false)开发阶段配合 EF Core 日志或 MiniProfiler，一眼就能看出重复 SQL 是否出现
基本上就这些。核心就一条：别让导航属性“偷偷查”，要么一次全拿，要么分步手动拿，要么干脆不拿实体。
