17370845950

显式加载适用于先查主体、后按需补数据的场景，需主体被上下文追踪且导航属性可写，通过Load()或Query()手动触发查询，避免N+1和不必要的数据传输。

EF Core 显式加载（Explicit Loading）适用于“先查主体、后按需补数据”的场景。它不依赖自动机制，而是由开发者在获取实体后，手动触发对导航属性的数据库查询，适合控制加载时机和范围，避免不必要的数据传输。

什么时候该用显式加载

当你已经拿到一个或多个实体（比如单个 Order），但此时还不确定是否需要它的 Customer 或 OrderItems，等业务逻辑判断后再决定加载——这时显式加载就比贪婪加载（Include）更灵活，也比延迟加载（Lazy Loading）更可控。

• 主体实体已存在，但导航属性为 null 或空集合（未被 Include，也没启用延迟加载）
• 需要根据条件动态决定是否加载某个关联数据（例如：仅当用户有权限时才加载订单明细）
• 想避免一次性加载大量关联数据，又不想引入代理和虚拟属性（延迟加载要求）

基础用法：Load() 加载整个导航集合

调用 DbContext.Entry(entity).Collection(navProp).Load() 或 .Reference(navProp).Load() 即可发起一次数据库查询，把关联数据填入导航属性。

• 一对多关系用 Collection：如 Entry(order).Collection(o => o.OrderItems).Load()
• 一对一/多对一关系用 Reference：如 Entry(order).Reference(o => o.Customer).Load()
• 执行后，对应导航属性会被赋值（集合会填充，引用对象会实例化）
• 每次调用都会发一次 SQL 查询，注意 N+1 风险——别在循环里无脑 Load

进阶用法：Query() 实现带过滤/排序的显式加载

如果不想加载全部关联数据，而是只取满足条件的部分（例如：只加载近 30 天的订单项），就要用 Query() 替代 Load()。它返回 IQueryable，支持 Where、OrderBy、Take 等链式操作。

• 示例：只加载状态为 “Shipped” 的订单项
• var shippedItems = context.Entry(order).Collection(o => o.OrderItems).Query().Where(oi => oi.Status == "Shipped");
• 执行 shippedItems.ToList() 才真正查询数据库
• 注意：Query() 不会自动赋值给导航属性，需手动赋值或直接使用查询结果

注意事项与常见坑

显式加载不是“黑盒魔法”，它依赖上下文追踪和实体状态。几个关键点要记牢：

• 实体必须被 DbContext 追踪（即通过查询获得，或已 Attach）。临时创建的对象无法显式加载
• 导航属性本身不能是 private set 或 init，否则 EF Core 可能无法赋值（建议保持 public setter）
• 若用了 AsNoTracking() 查询主体，后续无法调用 Entry().Collection().Load() —— 因为没被追踪
• 显式加载不改变原始查询逻辑，也不影响缓存；每次都是新查，适合低频、精准补数场景

基本上就这些。用得好，显式加载是精打细算数据加载的利器；用得随意，反而增加数据库往返次数。关键在“按需”二字。