根本原因是paginate()默认对主表count，而关联查询需对join结果集count，导致总数与分页数据不一致；正确做法是用显式join或wherehas()确保count与select语义统一。
ThinkPHP 的模型分页在关联查询场景下极易出错，根本原因不是语法写错，而是 paginate() 无法自动处理 JOIN 后的 COUNT 逻辑——它默认对主表 COUNT，但实际要分页的是关联结果集，总数和分页数据会严重 mismatch。
关联查询不能直接链式调用 paginate()
比如查「用户 + 最新订单」列表时写：UserModel::with('lastOrder')->paginate(10)，表面能跑，但 total() 返回的是用户数，不是“带订单的用户”数；更糟的是，如果某用户没订单，with() 会补 null，但分页仍按用户 ID 切片，导致第 2 页漏掉本该出现的有订单用户。
常见错误现象：
-
render()显示 5 页，点到第 3 页却返回空数组 -
$list->total()是 1000，但实际count()关联结果只有 320 条 - 开启
debug后发现两条 SQL：一条COUNT(*) FROM user，一条SELECT * FROM user LEFT JOIN order ... LIMIT 0,10，二者基数不一致
正确做法是手动构造关联查询并分页：
- 用
Db::table()显式写 JOIN，确保 COUNT 和 SELECT 针对同一结果集 - 避免
with()，改用子查询或原生 JOIN 字段（如order_id,order_amount） - 必须让
COUNT和LIMIT基于相同WHERE条件和JOIN逻辑
hasMany 关联分页必须用子查询兜底
当你真需要“每个用户带多条订单”的分页（比如导出明细），paginate() 完全失效——它只支持 1:1 或聚合，不支持 1:N 展开后分页。此时必须放弃模型分页，改用子查询模拟。
示例（查每个用户的最新 1 笔订单）：
$subQuery = Db::name('order')
->field('user_id, MAX(create_time) as max_time')
->group('user_id');
<p>$list = Db::name('user')
->alias('u')
->join([$subQuery => 'o'], 'u.id = o.user_id')
->join('order ord', 'ord.user_id = u.id AND ord.create_time = o.max_time')
->where('u.status', 1)
->order('u.id DESC')
->paginate(15);
</p>
关键点：
- 子查询先算出每个用户的最新时间，再 JOIN 回原表取完整订单，避免 N+1
-
paginate()此时作用在user + ord联合结果上，COUNT 和 LIMIT 语义一致 - 不能用
UserModel::has('orders')替代——它生成的EXISTS子句无法被paginate()正确 COUNT
belongsTo 关联字段参与 where 时，paginate() 会丢条件
比如查「状态为 1 的订单，且所属用户等级 > 5」：OrderModel::where('status', 1)->with(['user' => function($q){ $q->where('level', '>', 5); }])->paginate(10)，这个 where 只作用于 with() 的懒加载，不会下推到主查询，结果仍是所有 status=1 的订单，只是部分用户字段被过滤了。
必须把关联条件提到主查询：
- 用
join()显式关联，并在主where中写user.level > 5 - 或用
whereHas()：OrderModel::where('status', 1)->whereHas('user', function($q){ $q->where('level', '>', 5); })->paginate(10) -
whereHas()会生成正确子查询，COUNT 和分页数据一致，但注意：MySQL 5.7 下子查询 COUNT 性能较差，大数据量建议改 JOIN
游标分页在关联场景下几乎不可用
基于主键的游标分页（where('id', '>', last_id)）在关联查询中基本失效。因为 last_id 是主表 ID，但排序可能依赖关联字段（如 order.create_time），导致下一页跳过大量中间记录。
真实场景中容易忽略的点：
- 即使你强行用
order.create_time当游标字段，也必须保证该字段在关联结果中唯一（否则>会漏数据） - MySQL 对
JOIN + ORDER BY + WHERE组合的索引优化极敏感，没覆盖索引时，游标分页反而比OFFSET更慢 - 如果你的关联表数据更新频繁，游标值可能在翻页间隙被删/改，导致重复或丢失
结论：关联分页没有银弹。小数据量用 whereHas() + paginate()；中等数据量用显式 JOIN + paginate()；百万级必须拆成两步——先分页查主表 ID 列表，再用 IN 批量查关联数据。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
