关联查询分页必须拆分whereHas（筛选主模型）和with（预加载关联数据），否则无法正确过滤主表；whereHas是唯一能筛出“有已发布文章的用户”的入口，with仅控制预加载内容。
关联查询带条件分页，必须拆开写 whereHas 和 with，不能指望一个闭包同时搞定筛选和预加载。
whereHas 是筛选主模型的唯一入口
你写的 whereHas('posts', fn ($q) => $q->where('status', 1)) 这一行，才是真正把“只有发过已发布文章的用户”筛出来的关键。它生成的是 EXISTS 或 INNER JOIN 子句，直接决定哪些 User 能进最终结果集。
常见错误现象：
- 只写了
with(['posts' => fn ($q) => $q->where('status', 1)])，但没写whereHas→ 主模型全都在，只是关联数据被过滤了； - 把条件全塞进
with闭包里，以为能顺带筛选主表 → 完全无效，with只影响预加载的关联数据，不改变主模型集合； - 关系方法名大小写或命名不一致（比如模型里定义的是
post()，whereHas却传'posts'）→ 查询静默失败，返回空集合。
with 闭包只管预加载什么，不管主模型留不留
with(['posts' => fn ($q) => $q->where('published', true)->orderByDesc('created_at')]) 这段代码的作用，是让每个匹配的用户，只查出他自己的已发布文章，并按时间倒序排好——但它不会让“没发过已发布文章”的用户消失。
使用场景：
- 需要展示最新 3 篇文章？
with闭包里加limit(3)不起作用（Eloquent 不支持），得用子查询或withCount+ 后续处理； - 要对关联字段排序（如按评论数排序用户）？不能靠
with，得用withCount('comments')+orderBy('comments_count')； - PHP 版本低于 7.4？别用
fn语法，改用function ($q) { $q->where(...); }，否则报错。
分页时 with + whereHas 组合必须链式到底，paginate() 得放最后
正确写法：User::with(['posts' => fn ($q) => $q->where('published', true)])->whereHas('posts', fn ($q) => $q->where('published', true))->paginate(15)。Laravel 会先执行一条带 COUNT(*) 的查询（仅查 users.id），再用这批 ID 批量查 posts。
容易踩的坑：
- 在中间插了
get()或first()→ 分页失效，变成普通集合； - 用了
withCount('posts')又加whereHas('posts', ...)→COUNT结果可能归零，因为withCount默认用LEFT JOIN子查询，而whereHas是INNER JOIN，语义冲突； - 分页参数顺序写错，比如
paginate(15, 'page', 1)→ 第二个参数应是字段数组（如['*']），漏掉会触发默认值逻辑，有时导致字段缺失或报错。
大表 or 复杂关联时，count 容易成瓶颈
当主表数据量大、又带 whereHas + 多层关联时，paginate() 自动执行的 COUNT(*) 可能慢到卡住。这时不要硬扛，优先考虑：
- 换用
simplePaginate(15)：跳过总数统计，只查当前页数据，适合“下一页/上一页”场景； - 手动指定总数：
$total = User::whereHas('posts', ...)->toBase()->count()，再传给paginate(15, ['*'], 'page', 1, ['total' => $total])； - 游标分页：
cursorPaginate(20)，要求排序字段（如id）有唯一索引，彻底避开OFFSET和COUNT问题。
复杂点在于：whereHas 的嵌套层级（比如 user.posts.comments）必须一层层写，不能缩写；多条件之间默认是 AND，要 OR 得手动拼 whereRaw 或用高级查询构建器——这些地方一松手，SQL 就容易出错或性能骤降。
