ThinkPHP 8 的 cursor() 方法需严格按升序排序（如 →order('id', 'asc')）、确保排序字段非空且已索引，配合 →cursor(100, 'id', $next_cursor) 实现高效游标分页；不支持降序、复杂查询或直接跳页。
ThinkPHP 8 的 cursor() 方法怎么用
ThinkPHP 8.0+ 原生支持游标分页，但不是所有场景都适用——它只在查询带严格单调递增字段（如自增 id 或时间戳 create_time）且已建索引时才稳定。直接调 cursor() 却没设好排序和条件，查着查着就漏数据或重复。
- 必须显式指定升序排序，例如
->order('id', 'asc')；降序不支持游标（底层依赖前一页末尾值作为下一页起点） - 不能用
whereRaw或复杂子查询干扰主键/排序字段的可预测性 - 第一次请求不传游标参数时，框架默认从最小值开始，所以务必确保排序字段无 NULL 值，否则
MIN()结果不可靠 - 示例：
$list = Db::name('log')->where('status', 1)->order('id', 'asc')->cursor(100, 'id');返回结果里会多一个next_cursor字段，下一页带上它：->cursor(100, 'id', $next_cursor)
为什么不用 limit + offset 查百万级数据
Offset 越大，MySQL 越慢——它得先扫描跳过前面所有行。查第 10 万页（offset=9999900）时，即使只取 10 条，也可能触发全表扫描或临时文件排序。
- 游标查询本质是
WHERE id > ? ORDER BY id ASC LIMIT N，走索引范围扫描，响应时间基本恒定 - 但代价是：无法跳页（不能直接访问第 500 页），也不支持按模糊条件（如
LIKE）排序后分页 - 如果业务真需要“跳转到某页”，得换方案：预生成分页映射表，或改用 Elasticsearch
游标值被篡改或过期怎么办
ThinkPHP 默认把游标值 Base64 编码后拼进 URL，但没签名也没过期控制。用户手动改 next_cursor 参数，可能越界查到不该看的数据，甚至触发 SQL 错误。
- 生产环境务必开启游标签名：
Db::name('table')->cursor(100, 'id', null, true)，第四个参数为true时自动加 HMAC 签名 - 签名密钥由
app.cursor_key配置项控制，默认是应用密钥，建议单独配置 - 游标本身不含时间戳，所以“过期”得靠业务层实现——比如在生成游标时存一份 Redis 记录，2 小时后自动失效
- 遇到
Cursor value is invalid错误，大概率是签名失败或 Base64 解码出错，检查是否用了 URL-safe Base64（ThinkPHP 内部已处理，但自定义游标时要注意）
关联查询能用 cursor() 吗
不能直接用。一旦涉及 join、with 或子查询，ThinkPHP 的游标逻辑会失效——它只认主表的排序字段，关联后的结果集顺序无法保证单调。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法是：先用游标查主表 ID 列表，再用
whereIn('id', [...])拉取完整数据并关联 - 例如查带用户信息的日志列表：第一步游标取
log.id，第二步LogModel::with('user')->select($ids) - 注意两次查询间主表数据可能被删或状态变更，需根据业务容忍度决定是否加事务或版本字段校验
- 如果关联字段也要参与排序（如按用户名分页），说明模型设计有问题——游标分页只适合线性、可预测的序列，不适合关系型“视图”分页
