php分页预加载不能用offset因其性能随页码线性下降，正确做法是游标分页：基于上页末记录主键或时间戳条件查询，配合索引、base64url编码游标、严格校验、防抖限并发及失败降级处理。
PHP分页时为什么不能直接用 OFFSET 做预加载
因为 OFFSET 在大数据量下性能断崖式下跌，MySQL 扫描行数随页码线性增长，第1000页可能要跳过上百万行——这根本不是“预加载”，是卡死前的倒计时。
真实场景中，用户翻到后几页时，你希望提前拉取下一页数据（比如当前看第5页，后台静默请求第6页），但若还依赖 LIMIT 20 OFFSET 100，这个“预加载”本身就会拖慢当前页渲染，甚至触发超时。
- 用
OFFSET预加载 = 把两次慢查询塞进一次页面生命周期里 - 正确做法是改用游标分页（cursor-based pagination）：基于上一页最后一条记录的主键或时间戳做条件查询
- 例如上一页最后一条记录
id = 12345，预加载下一页就查WHERE id > 12345 ORDER BY id ASC LIMIT 21（多取1条用于判断是否有下一页） - 注意：必须有索引支撑
WHERE + ORDER BY字段，否则照样慢
PHP里怎么安全地生成预加载URL（不含SQL注入风险）
别拼接 $_GET 参数进SQL，也别把游标值裸露在URL里再手动解析——容易漏校验、类型错乱、被篡改。
- 游标值必须经过严格类型转换：
(int)$_GET['cursor']或filter_input(INPUT_GET, 'cursor', FILTER_VALIDATE_INT) - URL 中的游标建议用 base64url 编码混淆（非加密），避免暴露原始ID结构，同时防止特殊字符破坏路由：
base64_encode($last_id . ':' . time()) - 服务端解码后立刻校验格式和范围：
sscanf($decoded, '%d:%d', $id, $ts)，任一失败就拒绝请求 - 预加载接口应独立于主分页接口（如
/api/posts/next?cursor=xxx），响应只返回数据+是否还有下一页，不渲染HTML
前端触发预加载的时机和边界控制
预加载不是越早越好，也不是每页都该发请求。没控制好反而增加无效请求、浪费带宽、干扰监控指标。
立即学习“PHP免费学习笔记（深入）”；
- 推荐在用户滚动到当前页底部 80% 位置时触发，用 IntersectionObserver 比
scroll事件更轻量 - 必须加防抖：同一游标只允许发起一次预加载请求，用
Map缓存cursor → Promise即可 - 限制并发数：全局最多 1 个预加载请求在飞，后续请求排队或丢弃（
fetch不支持取消时尤其关键） - 如果当前页是最后一页（服务端返回
"has_next": false），立刻清空预加载状态，避免误触发
预加载失败时怎么降级不影响主流程
预加载本质是优化手段，失败了用户不该感知——但如果代码里写了 await preloadNext() 再渲染，那就把优化变成了阻塞。
- 预加载必须用
void fetch(...).catch(...)或Promise.resolve().then(preloadNext)脱离主线程 - 错误日志仅上报（如
console.warn('preload failed:', e)），不 throw，不 alert，不重试（重试由业务策略决定，非默认行为） - 服务端也要配合：预加载接口超时设为比主接口短（如主接口3s，预加载1.5s），并配置
fastcgi_read_timeout或类似项，避免拖累整个 PHP-FPM worker - 特别注意：Nginx 的
proxy_buffering off可能导致预加载响应被截断，测试时务必检查完整 JSON 结构
游标分页的边界处理比想象中麻烦：时间戳重复、主键不连续、软删除数据混入……这些都会让“下一页”跳过或重复。上线前至少用真实数据跑一遍 100 页以上的游标链验证。
