thinkphp分页总数错误最常见的原因是count()查询被错误应用group by或having条件，导致统计的是分组数而非原始总行数；应手动分离count查询，确保其与数据查询的筛选逻辑语义一致。
ThinkPHP 分页总数不对，最常见的原因是 count() 查询被错误地应用了 GROUP BY 或 HAVING 条件，导致统计行数与实际分页数据不一致。
为什么 count() 带 group/having 会导致总数错误
ThinkPHP 的分页方法（如 paginate()）内部会自动执行一次 COUNT(*) 查询来获取总条数。但如果原始查询中包含 group 或 having，框架默认会把它们“照搬”进 count 查询里——而 COUNT(*) 在分组后返回的是分组数，不是原始数据总行数，结果自然偏小甚至为 1。
如何检查是否误带了 group/having
打开你的分页代码，重点查看构造查询对象的部分：
- 是否有显式调用
->group('...')或->having('...') - 是否使用了关联查询（如
with()、join()）并配合了group，但未对 count 做隔离 - 是否在模型作用域（scope）或全局作用域中隐式添加了
group或having
正确写法：手动分离 count 查询
当业务确实需要分组查询时，应避免让分页自动推导 count，改用自定义总数：
$list = Db::name('order')
->field('user_id, sum(money) as total')
->group('user_id')
->having('total > 100')
->paginate([
'query' => request()->param(),
'total' => Db::name('order')->count(), // 明确用无条件 count
])
或者更精确地按业务逻辑算总数（如去重用户数）：
'total' => Db::name('order')->field('user_id')->group('user_id')->count()
其他易踩坑点
-
关联 + group 混用：用了
with('profile')又加group，count 会受关联表影响；建议先查主表 ID 列表，再通过where in关联 -
软删除字段干扰：如果模型启用了软删除，确保
count()查询也自动过滤了delete_time IS NULL，否则总数虚高 -
闭包查询未复现条件：用闭包传入
paginate()时，要确认闭包内没有漏掉group，或主动清空：->removeOption('group')
核心原则：分页的 total 必须反映你要分页的那批数据的“源记录数”，而不是分组/聚合后的结果数。只要 count 查询和数据查询的筛选逻辑保持语义一致，总数就不会错。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
