thinkphp不提供前端无限滚动分页的开箱即用方案，需前后端协同：后端用page()和count()提供标准json分页api，前端用intersectionobserver监听滚动并管理加载状态，避免重复请求与数据错乱。
ThinkPHP 本身不提供“前端无限滚动分页”的开箱即用方案，它只负责后端返回分页数据；真正实现滚动加载，得靠前端发请求 + 后端配合返回结构化数据，否则容易卡死、重复加载或漏数据。
ThinkPHP 的 paginate() 默认不兼容无限滚动
ThinkPHP 的 paginate() 方法默认渲染完整 HTML 分页栏（含上一页/下一页/页码），返回的是带 <div class="pagination"> 的字符串，不是 JSON。无限滚动需要的是纯数据接口，不是模板片段。
<ul>
<li>直接在 AJAX 请求里调 <code>index.html 路由？会拿到整个页面 HTML，解析成本高、易出错
paginate() 的分页逻辑？可以，但必须手动提取数据、跳过视图渲染$query->paginate(['type' => 'bootstrap', 'var_page' => 'page']) 只控制参数，不控制输出格式后端要提供标准的分页 API 接口
新建一个控制器方法（如 api/list），不调 fetch()，只返回 JSON：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
public function list()
{
$page = input('get.page/d', 1);
$limit = input('get.limit/d', 10);
$data = Db::name('article')
->order('id desc')
->page($page, $limit)
->select();
$total = Db::name('article')->count();
return json([
'code' => 0,
'data' => $data,
'meta' => [
'current_page' => $page,
'last_page' => ceil($total / $limit),
'per_page' => $limit,
'total' => $total
]
]);
}
- 别用
paginate()返回对象再转 JSON —— 它内部会自动计算总条数并附加分页属性，但字段名和结构不统一（比如render是 HTML 字符串） - 显式用
page($page, $limit)+count()更可控，避免paginate()在 API 场景下偷偷注入视图依赖 - 务必校验
$page和$limit，防止 SQL 注入或内存爆掉（例如传limit=999999）
前端滚动监听 + 防抖 + 加载状态管理
后端只是数据源，前端才是滚动加载的关键执行者。常见翻车点：快速滚动触发多次请求、到底部时重复加载、没判断是否还有下一页。
- 用
IntersectionObserver替代scroll事件监听，性能更好、兼容性够（IE 不支持，但 TP 项目通常不保 IE） - 加个
loading标志位，请求中禁止再次触发：比如if (loading || page >= last_page) return; - 不要等
window.innerHeight + window.scrollY >= document.body.offsetHeight——误差大，用目标占位元素更稳 - 示例关键逻辑：
axios.get('/api/list', { params: { page: nextPage++, limit: 10 } })，成功后追加到列表 DOM 并更新last_page
最常被忽略的是「服务端分页键是否稳定」：如果列表按 create_time 排序，而新数据实时插入，滚动加载时可能出现重复或跳过——这不是 TP 的问题，是业务排序字段本身不具备唯一性和稳定性。这时候得改用 id 的游标分页，TP 后端要配合做 WHERE 条件改写，而不是依赖 page/offset。
