游标查询不是offset+limit的替代，而是依赖单调唯一非空字段（如id或created_at）通过上一页末尾值作为下一页起点；Laravel 9.2+才原生支持cursorPaginate()，且仅限单字段升序排序、需索引，不返回total()。
游标查询不是 offset + limit 的替代写法
游标查询（Cursor-based Pagination）在 Laravel 中不等于用 skip 和 take 模拟分页。它依赖一个**单调、唯一、非空的排序字段**（通常是 id 或 created_at），通过上一页最后一条记录的该字段值，作为下一页查询的起点条件。Laravel 原生不提供 cursorPaginate() 方法（8.x 及更早版本），必须手动实现；9.2+ 才正式支持 cursorPaginate()，但仅限 Eloquent 查询且有严格前提。
Laravel 9.2+ 正确调用 cursorPaginate()
必须满足：排序字段是主键或带索引的唯一递增字段（如 id、created_at），且只允许一个 orderBy() 子句，不能混用 orderByDesc() 和 orderBy()，也不能用 orderByRaw()。
- ✅ 正确：
Post::orderBy('id')->cursorPaginate(10)、Post::orderBy('created_at')->cursorPaginate(15) - ❌ 报错：
Post::orderBy('id')->orderBy('title')->cursorPaginate(10)（多字段排序不支持） - ❌ 报错：
Post::orderByDesc('id')->cursorPaginate(10)（Laravel 9.2–9.51 对DESC支持不完整，9.52+ 修复，但需确认版本） - ⚠️ 注意：
cursorPaginate()返回的Paginator实例没有total()或lastPage()—— 它不计算总数，这是设计使然
手动实现游标查询（兼容所有 Laravel 版本）
核心逻辑是：取上一页最后一条记录的 id（或其它游标字段），下一页查 WHERE id > ?（升序）或 id （降序），再加 <code>limit + 1 判断是否有下一页。示例：
// 获取第一页（无游标）
$firstPage = Post::orderBy('id')->take(11)->get();
// 提取下一页游标（如果返回了 11 条，说明还有下一页，取第 10 条的 id 作 cursor）
$nextCursor = $firstPage->count() === 11 ? $firstPage->get(9)->id : null;
// 下一页请求传入 cursor=xxx，后端：
$cursor = request('cursor');
$posts = $cursor
? Post::where('id', '>', $cursor)->orderBy('id')->take(11)->get()
: collect();
// 前端需自行处理：截取前 10 条显示，第 11 条仅用于判断是否还有下一页
⚠️ 关键细节：游标字段必须有数据库索引，否则性能急剧下降；不能用 updated_at 这类可能重复的字段作游标，否则漏数据；若业务要求「按更新时间倒序」，建议用 (updated_at, id) 联合唯一约束并建复合索引，再用 whereRaw('updated_at 手动构造条件。
游标响应结构和前端配合要点
API 不该返回传统分页的 current_page、last_page，而应返回明确的游标链接：
- ✅ 推荐响应字段：
data（当前页数据）、next_cursor（字符串，可 base64 编码复合值，如base64_encode(json_encode(['id' => 123, 'updated_at' => '2024-01-01']))）、prev_cursor（如有需要） - ⚠️ 避免把游标暴露为纯数字 ID：防止被恶意枚举或跳转；尤其当游标字段是自增 ID 时，base64 或哈希混淆更安全
- ⚠️ 前端翻页时，必须把上一页末尾的游标原样传给下一次请求 —— 不能自己拼接或修改，否则断链
游标遍历真正难的不是写几行代码，而是对排序字段一致性的控制、索引有效性验证、以及前后端对“无总数”这一事实的接受——很多业务方卡在这一步，硬要加 total，结果要么全表扫描，要么放弃游标改回 offset。
