graphql分页必须用relay connection模型，返回edges、node、cursor和pageinfo，游标需基于排序字段生成唯一可比较值，查询参数仅支持first/last+after/before，且须在解析器中手动过滤和构建分页条件。
GraphQL里不用PHP翻页函数，得用游标或偏移分页模型
GraphQL本身不内置分页逻辑，offset、limit 或 PHP 的 array_slice() 这类服务端数组切片操作，不能直接套进 GraphQL 查询规范里。你写的 PHP 分页函数（比如封装了 paginate()）只适用于传统 REST 或模板渲染场景，在 GraphQL 中强行复用会导致响应结构错乱、游标失效、缓存不可靠等问题。
必须实现 Relay 兼容的 Connection 模型
主流前端库（如 Apollo、Relay）默认依赖 edges、node、pageInfo 等字段。PHP 后端需返回符合 Relay Connection Specification 的结构，而不是简单返回 data 数组加 total 字段。
-
edges是必有字段，每个元素含node（真实数据）和cursor（字符串，通常为 Base64 编码的 ID 或复合键） -
pageInfo必须包含hasNextPage、hasPreviousPage、startCursor、endCursor - 游标不能是页码或 offset，应基于排序字段（如
created_at DESC, id DESC）生成可比较的唯一值，例如：base64_encode("2024-05-01T12:00:00Z:123") - 查询参数只能接受
first/last+after/before，不能接受page或limit
用 Lighthouse 或 GraphQLite 时，分页逻辑要下沉到解析器内部
即使用了框架，也不能依赖其“自动分页”装饰器来处理业务排序或软删除过滤。比如 Lighthouse 的 @paginate 指令默认按 id 升序，而你实际需要按 updated_at DESC；又或者数据表有 is_deleted = 1 的记录，必须在分页前排除。
- 手动写解析器时，先用
DB::table()->where('is_deleted', 0)过滤，再根据aftercursor 解析出上一页末位的updated_at和id，拼成 where 条件：->where('updated_at', 'where(function ($q) use ($time, $id) { $q->where('updated_at', 'orWhere('updated_at', '=', $time)->where('id', ' -
first参数不是 LIMIT，而是“最多取 N 条”，需配合orderBy和游标条件做精确截断 - 不要在解析器里调用 Laravel 的
paginate()，它返回的是Paginator对象，字段名和结构与 Connection 不兼容
游标编码/解码容易漏掉时区和边界处理
最常踩的坑是把 MySQL 的 DATETIME 直接转字符串再 base64，但没统一时区（如 PHP 默认用系统时区，MySQL 可能用 UTC），导致游标解码后时间错位，分页跳行或重复。
- 所有时间字段在编码前强制转为 UTC 并格式化为 ISO 8601（如
$dt->setTimezone(new DateTimeZone('UTC'))->format('Y-m-d\TH:i:s\Z')） - 解码游标后，必须用相同时区重建
DateTime，不能直接new DateTime($str)（会按本地时区解析） - 复合游标（如
updated_at:id）要用固定分隔符（推荐:），且两边字段都需严格非空校验，避免注入式解析错误 - 如果用 UUID 或字符串主键，游标里不能只存 ID —— 必须带上排序字段值，否则无法稳定比较
游标不是透明透传的字符串，它是带语义的分页锚点。哪怕只是换了个排序字段，整个游标生成和验证逻辑都得重审。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
