ThinkPHP分页接口返回空数据的主因是paginate()误用：必须作用于未执行的查询构造器，而非select()/all()后的结果；需手动传入page/size参数；返回前不可调用toArray()；关联查询易致total()为0，应避免field()干扰COUNT或改用懒加载。
前后端分离场景下，ThinkPHP 分页接口返回空数据，不是前端没传参或前端渲染问题，而是后端分页逻辑本身被破坏了——最常见的是 paginate() 被误用、查询链中断、或参数未正确透传。
检查 paginate() 是否还作用在原始查询上
分页必须由 paginate() 接管未执行的查询构造器，不能在已执行的结果上调用：
- ❌ 错误写法：
UserModel::where('status', 1)->select()->paginate(10)——select()已把 SQL 执行完，返回的是数组或 Collection，paginate()此时只是对 PHP 数组做假分页，总数不准、无页码信息 - ❌ 错误写法：
$list = UserModel::all(); $list->paginate(10)——all()返回 Collection，它没有paginate()方法，会直接报错 - ✅ 正确写法：
$list = UserModel::where('status', 1)->paginate(15);—— 查询未执行，paginate()才能注入COUNT(*)和LIMIT逻辑
确认分页参数是否被前端正确传递并服务端识别
前后端分离通常用 AJAX 请求，GET 参数如 ?page=2&size=20 需显式读取，不能依赖默认行为：
-
paginate()默认只从$_GET['page']读当前页，不自动识别size或自定义参数名（如p） - 应手动传入完整配置：
UserModel::paginate(['listRows' => input('size/d', 15), 'page' => input('page/d', 1), 'var_page' => 'page']) - 若用 POST 提交查询条件（如搜索表单），分页链接仍是 GET，会导致翻页时条件丢失 → 数据变空。解决方式：前端把所有筛选参数拼进 URL query string，或改用 POST + JSON 请求体 + 每次带全条件的 AJAX 分页
验证返回结构是否被意外“解包”
接口返回前若调用了 toArray()、all() 或遍历了 $list，Paginator 对象就会转成普通数组，丢失 render()、lastPage()、total() 等方法：
立即学习“PHP免费学习笔记（深入）”；
- ❌
return json($list->toArray());→ 只剩数据，无分页元信息 - ✅ 应显式构造标准分页响应：
return json([
'data' => $list->items(),
'meta' => [
'current_page' => $list->currentPage(),
'last_page' => $list->lastPage(),
'per_page' => $list->listRows(),
'total' => $list->total(),
]
]);
排查关联查询或复杂条件导致 total() 为 0
用 with('profile') 或 join() 后 $list->total() 返回 0，常因 COUNT SQL 构建失败，降级为简单分页（无总数）：
- 避免在
paginate()前使用field()，尤其联合查询时字段别名或缺失主表字段会干扰 COUNT - 如必须关联，优先用
load()懒加载代替with()预载入；或拆成两步：先查主表分页 ID 列表，再按 ID 批量查关联数据 - 检查数据库索引是否生效 —— 若
COUNT(*)查询本身超时或走全表扫描，paginate()就会返回空结果集（尤其大数据量 JOIN 场景）
