currentpage()和lastpage()是paginator实例的动态计算结果，非配置项：前者从$_get['page']读值并校验，后者由ceil(total()/listrows)算出，依赖total()准确性。
currentPage() 和 lastPage() 是 Paginator 实例的动态计算结果，不是配置项
这两个方法返回的值不是你传进去的“当前页”或“总页数”，而是运行时根据查询条件、总数、每页条数实时算出来的。比如 currentPage() 会从 $_GET['page']（或你指定的 var_page）读值，再做一次 max(1, (int)$page) 校验；lastPage() 则是 ceil($total / $listRows) 的结果，依赖 total() 返回值。
常见误操作：
- 手动赋值
$paginator->currentPage = 2→ 无效，它是只读属性，没有 setter - 以为
lastPage()是数据库查出来的字段 → 其实它不查库，纯数学计算，所以如果total()不准（如带 LEFT JOIN 的复杂查询），lastPage()也会错 - 在模板里写
{$list->currentPage}（没括号）→ 报错或输出空，必须用{$list->currentPage()}
为什么 currentPage() 有时返回 1，即使 URL 带了 ?page=5
根本原因是 var_page 配置没对上。默认它找 $_GET['page']，但如果你改过参数名（比如用 p 或 pageNum），又没同步告诉 paginate()，它就 fallback 到 1。
检查点：
- 确认
paginate()第三个参数里是否设置了'var_page' => 'p' - 前端发请求时，是否真的带了
?p=5，而不是?page=5 - 有没有中间件或路由规则把 GET 参数过滤/重写了？比如某些安全插件会 strip 掉疑似分页参数
- API 场景下用了 POST/JSON 请求，但
request()->param()默认不包含 body 数据 → 得手动取：['page' => input('page/d', 1)]
lastPage() 为 0 或远小于预期，大概率是 total() 失效
lastPage() 完全依赖 total()。而 total() 来自那条 COUNT 查询 —— 这步在复杂 SQL 下容易出问题。
典型场景和对策：
- LEFT JOIN + GROUP BY 查询：COUNT(*) 会重复计数或漏计 → 改用子查询包装，或手动传
total参数：paginate(10, false, ['total' => $manualTotal]) - 用了
distinct但框架没识别 →total()可能偏大 → 同样建议手算后透传 - WHERE 条件里有变量未绑定（如拼字符串导致 SQL 报错），COUNT 查询静默失败 →
total()返回 0 → 检查日志里有没有 PDOException 或 SQL 错误 - 缓存了分页对象但数据已变 →
total()是旧值 → 不要复用 Paginator 实例，每次请求新建
render() 里用的 currentPage/lastPage，和你在代码里调用的其实是同一套逻辑
render() 输出 HTML 分页导航时，内部就是反复调用 currentPage()、lastPage()、hasPrevious() 等方法来判断要不要显示“上一页”“省略号”“第 5 页”。所以它们表现不一致，只有一种可能：你调用 render() 前，已经破坏了 Paginator 实例状态。
最常踩的坑：
- 执行了
$list->toArray()或json($list)→ 对象被序列化，后续render()调用失败或返回空字符串 - 对
$list做了->each()或->filter()→ ThinkPHP 6.3+ 的 Paginator 不支持链式修改原对象，这些方法返回新集合，原$list不变，但你可能误用了返回值 - assign 给模板的是
$list->items()，但模板里又试图调{$list->render()}→ 此时$list已是数组，没render()方法
Paginator 的状态很轻，但也很脆。别把它当普通对象去“加工”，需要变形就提前做，保持实例干净。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
