后端应统一用page和per_page参数，转为offset=(page-1)*per_page，per_page须白名单限制；响应必须含has_more字段；滚动加载需加请求锁和abortcontroller防重复；深分页应改用游标分页。
PHP 后端怎么返回分页数据给 Ajax
关键不是“怎么加载”，而是“怎么让前后端对齐分页逻辑”。后端必须提供可预测的、带边界控制的数据切片，否则前端滚动加载会重复、漏项或卡死。
常见错误现象：offset 算错导致第 2 页从第 11 条开始、但实际第 10 条没返回；或者用 page=2 但数据库 LIMIT 偏移量写成 20（应是 10）；更隐蔽的是没校验 limit 上限，被恶意请求拖垮数据库。
- 统一用
page和per_page参数（别混用offset/limit），后端转成offset = (page - 1) * per_page -
per_page必须硬编码或白名单限制（如只允许10、20、50），防止传per_page=10000 - 返回 JSON 里必须带
has_more字段（布尔值），而不是靠“返回条数是否等于per_page”来判断——因为最后一页可能刚好凑满，但其实没下一页了 - 示例响应结构：
{"data": [...], "has_more": true, "next_page": 3}
Ajax 滚动加载时怎么避免重复请求
滚动触发太频繁，或用户手速快，很容易发一堆并发请求，后端压力大，前端还可能把旧数据覆盖新数据。
使用场景：用户快速下滑、网络慢时反复触发、页面重进后自动加载首屏。
立即学习“PHP免费学习笔记（深入）”；
- 加请求锁：
isLoading状态变量，发起请求前设为true，成功/失败后才置false，锁住后续触发 - 取消上一个未完成的请求：用
AbortController（现代浏览器），fetch传{ signal }，调用abort()即可 - 防抖不适用滚动加载——它会丢请求；节流也不合适——可能卡住真实加载时机。真要控频，只在
has_more === false后彻底停监听 - 不要在
scroll事件里直接调fetch，先requestIdleCallback或setTimeout(..., 0)微任务调度，避免阻塞滚动帧
MySQL 分页深翻性能差，PHP 怎么绕过 OFFSET
当 OFFSET 超过几万行，LIMIT 10 OFFSET 100000 会全表扫到第 100000 行再取 10 条，PHP 端等得再久也没用。
性能影响：响应时间从 20ms 涨到 2s+，DB CPU 拉满，连接池耗尽。
- 改用游标分页（cursor-based）：不再依赖
OFFSET，而是记录上一页最后一条的id或created_at，下一页查WHERE id > ? ORDER BY id LIMIT 10 - PHP 中生成游标值要严格 URL 安全：用
base64_encode((string)$last_id)，别直接拼进 SQL - 游标分页不能跳页（比如直接点“第 50 页”），但滚动加载本来就不需要跳页，反而更稳
- 如果必须支持跳页且数据量不大（INDEX (status, created_at, id)，让
ORDER BY created_at DESC LIMIT 10 OFFSET N走索引覆盖
PHP 分页接口被刷怎么办
滚动加载接口比普通页面更容易被爬虫或脚本高频调用，尤其当返回字段含敏感信息或没做频率限制时。
容易踩的坑：只在 Nginx 层限流，但 PHP 还是会执行查询；或用 $_SESSION 记录次数，却忘了分布式部署下 session 不共享。
- 在 PHP 入口处加轻量级限流：用 Redis 的
INCR+EXPIRE，例如每 IP 每分钟最多 60 次，超限直接http_response_code(429) - 不要验证 Referer 或 User-Agent——太容易伪造；重点看请求头里有没有
X-Requested-With: XMLHttpRequest（Ajax 标准头） - 对未登录用户，返回数据要精简：去掉
user_id、email等字段，哪怕前端 JS 里写了也别给 - 如果用了游标分页，游标值本身可加签名（如
base64_encode($id . ':' . hash_hmac('sha256', $id, $secret))），防止用户篡改 ID 跳查
事情说清了就结束。最常被忽略的是：游标分页和传统分页不能混用，一旦后端切到游标，前端就必须按游标逻辑走，包括初始请求也要带 cursor=（哪怕为空），否则第一页和后续页数据对不上。
