PHP对接前端瀑布流只需提供标准分页接口：用filter_input校验page或last_id参数，按(page-1)*limit算offset或用created_at+id游标查询，返回数据时必带has_more字段；游标分页可避免高并发下OFFSET导致的数据漏/重。
PHP分页怎么对接前端瀑布流？
瀑布流本身不关心后端怎么分页，它只认“下一页数据接口”——所以 PHP 不需要特殊“瀑布流分页”，只需要提供标准的、带偏移量的分页接口。关键不是写多炫的 PHP 逻辑，而是让 offset 和 limit 对得上前端滚动加载时传来的页码或游标。
- 前端通常传
page=2或last_id=123，PHP 要据此算出对应OFFSET；用page就是(page - 1) * limit，用last_id就走游标分页（更稳） - 别直接在 SQL 里拼
$_GET['page']，必须过滤：用filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT)，非法值就返回空数组或 400 - 返回 JSON 时，除了数据，至少带上
has_more字段（布尔值），告诉前端“还能不能继续拉”，比靠数量判断更可靠
为什么用游标分页（cursor-based）比 offset 分页更合适？
因为瀑布流滚动快、用户可能跳着加载、数据实时增删——OFFSET 在高并发写入场景下会漏数据或重复。比如第 2 页刚查完，新内容插入到第 1 页末尾，下次查第 3 页就可能跳过几条。
- 游标分页依赖有序字段（如
created_at+id），查询条件是WHERE created_at - PHP 返回时，把最后一条的
created_at和id打包进next_cursor字段，前端下次请求带上它 - MySQL 8.0+ 支持窗口函数，但游标分页在 5.7 也能跑，兼容性更好；注意
created_at要建联合索引：INDEX(created_at, id)
PHP 返回 JSON 时容易踩哪些坑？
瀑布流前端（尤其是 JS 框架）对响应结构很敏感，错一个字段名或类型就卡住加载。
- 必须设
Content-Type: application/json; charset=utf-8，否则某些浏览器或 axios 会解析失败 - 用
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_INVALID_UTF8_SUBSTITUTE)，避免中文变 null 或报错 - 空数据别返回
null或空字符串，统一返回[]数组；has_more必须是布尔值，不能是字符串"false" - 别在 PHP 里用
header('Access-Control-Allow-Origin: *')做跨域——该由 Nginx / Apache 配置，PHP 中加反而容易被覆盖或重复
如何让 PHP 分页接口支持“加载中”和“到底了”状态？
前端靠后端返回的元信息驱动 UI 状态，PHP 只需稳定输出两个信号：是否还有下一页、当前页有没有数据。
立即学习“PHP免费学习笔记（深入）”；
-
has_more：严格等于true或false，不要用0/1或字符串 - 如果查不到数据（比如游标已到底），仍要返回
{"items": [], "has_more": false}，而不是 404 或空响应 - 别为了“省一次查询”在 PHP 里预估总数——瀑布流不需要总页数，估算反而不准；真要显示“共 XX 条”，改用 Elasticsearch 或单独缓存计数
实际最难的不是写 PHP 分页逻辑，而是前后端对“游标格式”“空响应定义”“错误码含义”的约定是否一致。一个字段命名不统一，就能让瀑布流在某次上线后突然停止加载。
