EF Core 处理复杂查询，核心不是“写得越长越高级”，而是选对方式、控住范围、避开陷阱。它不强制你手写 SQL，但要求你理解导航、加载策略和查询翻译逻辑。下面这些技巧，都是真实项目里反复验证过的关键点。
用 Include + ThenInclude 精准加载多层关联
这是最常用也最容易出错的方式。关键在于：Include 必须从根实体开始，ThenInclude 只能接在上一级导航属性之后。
正确写法（四级关联）：.Include(u => u.Orders).ThenInclude(o => o.OrderItems).ThenInclude(oi => oi.Product) 错误写法：.Include(u => u.Orders.OrderItems) —— 编译不过，也不符合链式语义 如果某层是集合（如 Orders），下一层必须用 ThenInclude；如果是单个引用（如 Order.Customer），则仍可用 ThenInclude 或直接 Include拆分查询（AsSplitQuery）防笛卡尔爆炸
当一个查询包含多个一对多关系（比如用户 + 订单 + 订单项），用默认的单 SQL JOIN 容易产生大量重复数据，内存暴涨甚至超时。这时加 .AsSplitQuery() 就很关键：
EF Core 会把一个大查询拆成多个独立 SQL，按主键合并结果 适合“1对多再对多”的场景，比如 User → Posts → Comments 注意：不能和某些聚合操作（如 Count()）混用，且事务中需谨慎（可能跨多次数据库往返）用 Join 显式连接，只取需要的字段
当你不需要整个实体，只要几个字段（比如订单号、客户名、产品价格），用 LINQ 的 join 比 Include 更轻量：
避免加载整张 Customer 表或 Product 实体，减少序列化开销 示例：context.Orders.Join(context.Customers, o => o.CustomerId, c => c.Id, (o, c) => new { o.Id, c.Name }) 配合 Where 和 Select，生成的 SQL 干净，数据库压力小用投影（Select）代替实体加载
多数复杂查询其实不需要完整实体对象，只需要展示用的数据。直接 Select 匿名类型或 DTO：
不触发导航属性加载，天然规避 N+1 可自由组合字段，甚至加计算列（如 TotalPrice = oi.Quantity * p.Price） DTO 类建议用 record 或简单 class，EF Core 5+ 支持自动映射基本上就这些。不复杂，但容易忽略加载策略和数据形状设计。真正卡顿的查询，90% 出在没控制好“查什么”和“怎么连”，而不是 EF Core 本身慢。
