应使用cursorpaginate()替代paginate()：一、选用唯一单调字段（如id）作游标并建索引；二、在orderby后直接调用cursorpaginate()且不提前执行查询；三、响应中返回next_cursor和has_more，不提供总数；四、为排序字段建联合索引；五、禁用with()预加载，改用select+join或分批查询。
如果您在 Laravel 应用中处理大数据量列表（如用户导出、日志检索或 API 分页响应），发现传统 paginate() 方法因 COUNT(*) 和深分页导致内存飙升或响应延迟，则很可能是由于 OFFSET 跳跃式扫描引发的性能瓶颈。以下是使用 cursorPaginate() 实现高性能、低内存消耗分页的具体操作步骤：
一、确认排序字段满足游标分页要求
游标分页依赖一个唯一、单调递增且有数据库索引的字段作为游标锚点，否则将出现数据遗漏或重复。该字段必须能稳定标识每条记录的全局顺序。
1、优先选用自增主键 id 字段，确保其在表上已建立主键索引；
2、若需按时间排序，可组合使用 created_at 与 id（如 orderBy('created_at', 'desc')->orderBy('id', 'desc')），避免同一毫秒内多条记录导致游标歧义；
3、禁止使用 updated_at（可能回滚）、score（存在大量重复值）或 title（无序且高频重复）作为游标字段。
二、在控制器中调用 cursorPaginate() 方法
该方法跳过 COUNT 查询与 OFFSET 计算，仅基于上一页末尾记录的排序字段值构造 WHERE 条件，从而实现恒定查询复杂度与极低内存占用。
1、在 Eloquent 查询链末尾直接调用 cursorPaginate(1000)，传入每页期望条数；
2、确保 orderBy() 在 cursorPaginate() 之前显式声明，且字段与索引一致；
3、若需动态筛选，使用 when() 链式条件，但所有 where/orderBy 必须在 cursorPaginate() 前完成；
4、示例代码中不得调用 get()、first() 或 toArray() 等触发执行的方法，否则 cursorPaginate() 将失效。
三、构造符合规范的 API 响应结构
游标分页不返回总条数和总页数，客户端需通过游标字符串持续请求下一页，服务端据此生成下一条 WHERE 子句，因此响应必须携带可解析的游标标识及翻页状态。
1、从分页器实例提取 $paginated->nextCursor()->encode() 获取 Base64 编码的游标字符串；
2、调用 $paginated->hasMorePages() 判断是否还有下一页；
3、响应 JSON 中必须包含 data（当前页数据）、next_cursor（下一页游标）、has_more（布尔值）三项关键字段；
4、禁止在响应中返回 total、last_page 或 from/to 等基于总数的元信息，因其与游标逻辑冲突。
四、在数据库层面配置必要索引
游标分页的性能优势完全依赖数据库能否高效定位游标起始位置，若缺失对应索引，WHERE 条件仍将触发全表扫描，失去优化意义。
1、对主游标字段（如 id）确认已有主键或唯一索引；
2、若使用复合排序（如 ORDER BY created_at DESC, id DESC），必须创建联合索引 INDEX idx_created_id (created_at, id)；
3、运行 EXPLAIN 检查查询是否命中索引，重点关注 type 是否为 range 或 ref，而非 ALL；
4、对筛选字段（如 country_id）也建议单独建索引，避免 WHERE 过滤阶段成为瓶颈。
五、处理关联数据与字段选择限制
cursorPaginate() 不支持 Eloquent 的 with() 预加载，因其底层使用原生 SQL 游标机制，无法安全注入 JOIN 语句。强行使用会导致游标错位或查询失败。
1、如需关联字段，改用 select() 显式列出所有需要的列，并通过 JOIN 手动拼接查询；
2、若业务强依赖模型关系访问器（如 $user->profile->avatar），应放弃游标分页，改用带缓存的 paginate() 或 simplePaginate()；
3、对必须预加载的场景，可采用前端分批请求策略：先获取 ID 列表，再以 whereIn('id', [...]) 批量查关联数据；
4、始终避免在游标查询中使用 groupBy、distinct 或子查询，这些语法与 cursorPaginate 不兼容。
