ThinkPHP分页总数错误主因是COUNT未执行或不合法：paginate()必须作用于未执行查询，否则total()为0；GROUP BY等复杂查询需手动处理COUNT；URL参数未透传会导致翻页条件丢失。
ThinkPHP分页总数错误，核心问题往往不是“算错了”，而是“根本没去算”或“没法算”。最常见的是 total() 返回 0 或远小于实际数据量，导致分页链接不显示、页码跳转失效、甚至整个分页对象为空。修复关键在于确认分页逻辑是否真正触发了 COUNT 查询，以及该查询在当前 SQL 结构下是否合法。
paginate() 必须作用于未执行的查询构造器
这是总数出错的第一大原因。一旦查询被提前执行（如调用 select()、all()、find()），paginate() 就只能对 PHP 数组做假分页，不会生成 COUNT(*)，total() 必然为 0 或错误值。
- ❌ 错误写法：UserModel::where('status', 1)->select()->paginate(10) —— select() 已执行 SQL，paginate() 失效
- ❌ 错误写法：$list = UserModel::paginate(15)->toArray(); $list->render() —— toArray() 后对象丢失，render() 报错或空白
- ✅ 正确写法：UserModel::where('status', 1)->paginate(15)
- ✅ 正确写法（带参数）：UserModel::where('status', 1)->paginate(['list_rows' => 20, 'page' => input('page/d', 1)])
GROUP BY 查询必须手动处理总数
带 GROUP BY 的分页会直接导致 total() 返回 0，因为框架底层尝试执行 SELECT COUNT(*) FROM table GROUP BY xxx，这在 MySQL 中语法非法。
- 典型场景：按月份统计日志 Db::table('log')->group('DATE_FORMAT(create_time,"%Y-%m")')->paginate(10)
- 解决方法：改用子查询 COUNT，或手动计算总数。例如先查分组结果 ID 列表，再用 Db::name('log')->where('id', 'in', $ids)->count()；更稳妥的是用原生 SQL 或闭包传入自定义 count 查询
- 注意：with() 关联 + field() 字段限制也可能干扰 COUNT，建议关闭字段裁剪或显式指定 count 查询
检查分页对象状态与环境配置
即使查询写法正确，total() 仍可能为 0，需逐层验证分页对象是否健康。
立即学习“PHP免费学习笔记（深入）”；
- 打印 $list->total() 和 $list->count()，确认是否均为 0；若 items() 有数据但 total() 为 0，基本可断定 COUNT 查询失败
- 检查数据库配置中 'collection' => false（TP6 默认为 true 时可能将分页结果转为 Collection，丢失 Paginator 方法）
- 确认分页驱动类存在且路径正确，尤其是自定义驱动时；驱动加载失败会导致 render() 静默返回空字符串
- 确保 $list->total() > 0，部分驱动在 total 为 0 时主动跳过渲染，页面就看不到分页栏
URL 参数未透传导致翻页条件丢失
总数本身没错，但翻页时条件消失，造成“第二页查不到数据”，看起来像总数不准。本质是 paginate() 生成链接时未携带原有 where 条件参数。
- 使用 input() 显式传参，例如：->paginate(['query' => request()->param()])
- 若用 URL 路由参数（如 /user/index/page/2），需确保路由变量被自动合并进分页链接，否则需手动构造 query 数组
- 特别注意 POST 请求分页——paginate() 默认只读 GET 参数，POST 条件需自行提取并注入 query
