应采用游标分页替代 OFFSET 分页：用上一页最后记录的唯一有序字段（如 id）作为查询条件，避免全表扫描；同时严格校验用户输入、分离总数统计、正确维护分页 URL 参数。
分页时 OFFSET 越大越慢，怎么办
MySQL 的 LIMIT offset, size 在 offset 很大时（比如 100 万行后取 20 条），会真实扫描前 offset + size 行再丢弃，性能断崖式下跌。
真正高效的做法是「游标分页」（Cursor-based Pagination）：用上一页最后一条记录的排序字段值作为下一页起点，避免依赖 OFFSET。
- 适用场景：列表按时间/ID 严格递增、不频繁更新、不要求跳转任意页（如日志流、消息流）
- 关键点：必须有唯一且有序的索引字段，比如
id或created_at+id - 示例 SQL：
SELECT * FROM posts WHERE id > 12345 ORDER BY id ASC LIMIT 20（上一页最后一条id是 12345） - PHP 中需校验该
id是否真实存在，防止被篡改或越界
$_GET['page'] 直接参与 SQL 拼接，很危险
用户传入的页码不加过滤就塞进 OFFSET 计算，等于给 SQL 注入开了后门。哪怕只是整数，也必须强制类型转换或白名单校验。
- 错误写法：
$page = $_GET['page']; $offset = ($page - 1) * $size;——$_GET['page']可能是1; DROP TABLE users; - 正确做法：用
(int)强转 + 边界检查，例如$page = max(1, (int)$_GET['page']); - 更稳妥：用
filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT)，失败返回false - 永远不要把未处理的
$_GET或$_POST值拼进 SQL，哪怕你“确定”它只是数字
总数查询 COUNT(*) 和分页查询分离，别合在一个事务里硬扛
显示「共 12847 条，第 3 页 / 共 643 页」看起来合理，但每次请求都执行 SELECT COUNT(*) FROM ... WHERE ...，尤其带复杂 JOIN 或 WHERE 条件时，I/O 和 CPU 开销巨大。
立即学习“PHP免费学习笔记（深入）”；
- 可接受方案：缓存总数（如 Redis 存
post_count_v2），仅在数据批量变更后刷新 - 轻量替代：用
SQL_CALC_FOUND_ROWS（已废弃）或两次查询（不推荐），不如直接放弃精确总页数 - 更现实的做法：只查当前页数据 + 多查一条，判断是否有下一页（
LIMIT 21，只展示前 20 条），不显示总页数 - 注意：
COUNT(*)在 InnoDB 上仍需扫描索引，不是 O(1)，表越大越明显
分页链接里的参数没处理好，URL 乱成一团
用户在搜索页翻页，结果 ?q=php&page=2 变成 ?page=2，搜索条件丢了；或者多个筛选参数重复叠加，生成 ?cat=1&cat=2&sort=date&sort=title。
- 核心思路：用
http_build_query(array_merge($_GET, ['page' => $next]))维持原有参数 - 记得先
unset($_GET['page'])再合并，避免 page 参数冲突 - 对敏感参数（如
token、signature）要主动过滤，别一股脑带过去 - URL 编码问题：中文或特殊字符在
$_GET中已是解码状态，http_build_query会自动再编码，无需手动urlencode
分页看着简单，但每一步都在和数据库、HTTP、用户预期较劲。最容易被忽略的是：游标分页无法跳转任意页，而传统分页又扛不住大数据量——选哪种，得先想清楚你的「下一页」到底意味着什么。
