该用 loadmissing() 而不是 load() 时：当不确定关联是否已加载且需避免重复查询，loadmissing() 仅补查缺失关联，而 load() 会无脑重查触发额外 sql。
什么时候该用 loadMissing() 而不是 load()
当你不确定关联是否已加载，又不想重复查库时，loadMissing() 是唯一安全的选择。它会跳过已加载的关联，只补查缺失的——而 load() 无脑重查，哪怕数据已经在内存里，也会触发新 SQL。
常见错误现象：N+1 没解决，反而因为反复 load() 加剧了查询次数；或者在循环中对同一个模型多次调用 load()，实际执行了 5 次相同关联查询。
- 使用场景：控制器里处理一批
User后，临时需要补查他们的profile，但部分用户可能已在上一步通过with('profile')预加载过 - 参数差异：
loadMissing('profile')和loadMissing(['posts', 'profile'])都支持，和load()一样接受字符串或数组 - 性能影响：避免重复查询，但不会触发懒加载（即不等你访问属性才查），它是在调用时立即补查
belongsTo 关联为什么不能靠延迟加载“救”？
因为 belongsTo（比如 Post->user()）默认是惰性求值的：你不访问 $post->user，它根本不会查库。所谓“延迟加载”在这里是天然存在的，不需要额外操作。
容易踩的坑：有人看到 hasMany 用 loadMissing()，就以为 belongsTo 也要手动“延迟”，结果写了 $post->loadMissing('user')——这反而让本可避免的查询提前发生了，还丢失了 Laravel 的自动缓存机制（$post->user 第二次访问本该直接取内存对象）。
- 正确做法：直接访问
$post->user，Laravel 自动按需查一次并缓存；如需确保已加载且不想触发查询，用$post->relationLoaded('user')判断 - 兼容性注意：Laravel 8+ 才有
relationLoaded()，低版本需用isset($post->user)或$post->user !== null辅助判断（但不严谨，因 null 可能是真实数据）
用 when() + with() 控制预加载开关比事后 loadMissing() 更高效
如果业务逻辑里，某个关联是否需要加载，取决于请求参数或条件（比如 ?with_profile=1），那在查询构建阶段就决定，比查完再补更省资源。
性能影响明显：前者只发 1 条带 JOIN 或子查询的 SQL；后者至少 2 条（主表 + 关联表），还多一次 PHP 对象遍历。
- 实操示例：
User::query()->when(request('with_profile'), fn ($q) => $q->with('profile'))->get() - 注意点：
when()的闭包里必须返回查询实例（$q），漏掉return或写成表达式会导致失效 - 嵌套关联慎用：
with(['posts.comments'])在when()中开启后，若数据量大，可能比单层更吃内存，要结合分页和 select 约束字段
loadMissing() 在 Eloquent Collection 上的行为陷阱
对集合调用 loadMissing() 时，它会对**集合中所有模型**统一补查——哪怕其中只有 1 个缺关联，其余都已加载，也会为全部发起查询（Laravel 不做个体粒度判断）。
这跟单个模型上调用行为不同：单个模型是真·按需；集合是“全有或全无”的批量补查，容易误伤性能。
- 典型误用：先
$users = User::with('company')->get()，再$users->loadMissing('profile')—— 结果 profile 查了 N 次（N 是用户数），而不是只查缺的那几个 - 替代方案：用
$users->filter(fn ($u) => ! $u->relationLoaded('profile'))->pluck('id')拿出缺的 ID，再一次性Profile::whereIn('user_id', ...)->get()手动关联，效率高得多 - 调试建议：打开
DB::enableQueryLog()，看实际执行了几条 SQL，别只信方法名里的 “Missing”
真正难的不是知道有 loadMissing()，而是判断它在哪一层（单模型 / 集合 / 嵌套关系）会悄悄放大查询量。一不留神，省下的 N+1 就被新的批量查询吞掉了。
