显式加载适用于先查主体、后按需补数据的场景，需主体被上下文追踪且导航属性可写，通过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
- 示例：只加载状态为 “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() —— 因为没被追踪
- 显式加载不改变原始查询逻辑，也不影响缓存；每次都是新查，适合低频、精准补数场景
基本上就这些。用得好，显式加载是精打细算数据加载的利器；用得随意，反而增加数据库往返次数。关键在“按需”二字。
