该用with()还是load()取决于关联数据是否确定必查：with()在主查询时预加载，适合稳定1–2层必查场景；load()延迟加载，适合按需获取，避免冗余查询和深层嵌套性能问题。
什么时候该用 with() 而不是 load()
关键看数据获取时机：with() 是在主查询时就拼接 JOIN 或发起预加载 sql，适合「确定要查关联数据」的场景；load() 是模型已查出后再补查关联，适合「可能用、也可能不用」的懒加载逻辑。比如列表页默认不显示用户头像，点开详情才需要，那就该用 load() 延迟到点击后执行。
常见错误是全写成 with()，结果每次列表都把没用到的 posts、profile 全查出来，反而拖慢首屏。更隐蔽的问题是嵌套太深：with(['user.posts.comments.author']) 会触发 4 张表的预加载，如果某层数据为空或量大，mysql 优化器容易放弃使用索引。
- 优先用
with()处理「稳定必查」的 1–2 层关联 - 对可选字段（如编辑态才显示的审核记录），改用
load()按需触发 - 避免三级以上嵌套预加载，拆成多次明确的
with()调用更可控
whereHas() 和 withCount() 别混着用
想查「有至少一条未读消息的用户」，直接写 User::whereHas('messages', fn ($q) => $q->where('read', false))->get() 就够了；但如果同时还要显示每个用户未读数，很多人会补一句 withCount(['messages as unread_count' => fn ($q) => $q->where('read', false)]) —— 这会导致生成两条独立子查询，性能翻倍还容易错位。
正确做法是只用 withCount()，它本身支持条件闭包，且结果直接挂载为属性：withCount(['messages as unread_count' => fn ($q) => $q->where('read', false)]) 查出来的模型自动带 $user->unread_count，不需要再 whereHas() 过滤。
-
whereHas()仅用于 WHERE 条件过滤，不返回关联数据 -
withCount()既能统计又能当条件用，但别和whereHas()叠加同一关系 - 统计类需求优先走
withCount()，避免 N+1 和重复查询
预加载里怎么安全地加 select()
默认 with('user') 会查 users 表所有字段，但页面往往只用 name 和 avatar。加 select() 能减少网络传输和内存占用，但必须包含外键字段，否则 laravel 关联匹配失败。
比如 Post::with(['user' => fn ($q) => $q->select('id', 'name', 'avatar')]) 看似精简，但会报错：因为 posts.user_id 和 users.id 匹配时，users.id 不在 select 列表里。正确写法是强制带上外键：select('id', 'name', 'avatar') 中的 id 必须对应关联字段名（这里是 users.id）。
- 只要用了
select()，外键字段（通常是id）必须显式写出 - 关联表字段别名不影响匹配，但主键别名会导致关联断裂
- 配合
toBase()->toSql()打印 SQL，确认生成的 JOIN 是否含你想要的字段
复杂条件预加载要用 constrain() 而不是闭包里写 where()
想查「每个用户的最新一条订单」，有人这么写：with(['orders' => fn ($q) => $q->orderByDesc('created_at')->limit(1)]) —— 这实际无效。Laravel 预加载不支持在闭包里用 limit 或 orderBy，它只会忽略这些调用，最后还是查出全部订单再 PHP 层截断，N+1 毫无改善。
正确方式是用约束式预加载：withCount(['orders as latest_order' => fn ($q) => $q->latest()->limit(1)]) 不行，得换思路：用子查询或数据库原生窗口函数。更实用的解法是先查出各用户的最新订单 ID，再用 whereIn() 关联加载，或者直接上 hasMorph() + 自定义关系方法。
-
with()闭包里只认select()、where()、with()这类过滤型方法 -
orderBy、limit、groupBy在预加载中会被静默丢弃 - 真要取「每个关联的最新一条」，优先考虑数据库侧方案（如 MySQL 8.0 的 ROW_NUMBER()）或分两步查
预加载不是万能胶，它解决的是「本该一次查完却拆成多次」的问题；但如果你的关联逻辑本身需要动态排序、分页或聚合，硬塞进 with() 只会让 SQL 更难调试、更难命中索引。真正卡顿的地方，往往不在有没有预加载，而在关联字段有没有索引、外键是否加了索引、以及预加载的粒度是否和前端展示强绑定。