<p>分页核心是计算offset = ($page - 1) <em> $per_page，需校验$page为正整数、$per_page为正数，用(int)强转并max(1, ...)防护；SQL须预处理绑定limit/offset；大偏移量应改用游标分页；COUNT()查总数最可靠；链接生成用http_build_query保留筛选参数。</p>
分页核心公式：如何算出当前页的起始记录位置
分页本质是“跳过前 N 条，取 M 条”，关键靠 offset 和 limit。PHP 里没有内置分页函数，必须手动计算 offset = ($page - 1) * $per_page。注意：$page 必须是正整数，$per_page 不能为 0 或负数，否则 SQL 会报错或逻辑错乱。
常见错误现象：
- 用户传入
page=0或page=-1，导致offset为负，MySQL 报错SQLSTATE[42000]: Syntax error or access violation - 没对
$page做整型强制转换，字符串如"1abc"被转成1，但"abc1"变成0，直接触发负偏移
实操建议：
- 用
(int)强转并判断最小值：$page = max(1, (int)$_GET['page'] ?? 1);
- 统一用
ceil($total / $per_page)算总页数，别用floor或四舍五入 - 如果数据库用的是 PostgreSQL，
OFFSET同样适用，但空结果集时不会报错，需额外判断是否有数据
SQL 查询怎么写才安全又高效
直接拼接 $_GET 参数进 SQL 是高危操作。必须用预处理语句，且只允许控制 limit 和 offset 两个值。
立即学习“PHP免费学习笔记（深入）”；
错误写法（危险）：
$sql = "SELECT * FROM article LIMIT " . $_GET['limit'] . " OFFSET " . $_GET['offset'];
正确写法（PDO 示例）：
$stmt = $pdo->prepare("SELECT * FROM article ORDER BY id DESC LIMIT :limit OFFSET :offset");
$stmt->bindValue(':limit', $per_page, PDO::PARAM_INT);
$stmt->bindValue(':offset', $offset, PDO::PARAM_INT);
$stmt->execute();
性能注意点：
- 大表分页时，
OFFSET越大越慢（MySQL 需扫描前面所有行），超 10 万行建议改用游标分页（基于id > last_id） -
ORDER BY字段必须有索引，否则排序本身就会拖垮性能 - 不要在分页 SQL 里用
SELECT *，只查需要字段，减少网络和内存开销
如何获取总记录数并避免两次查询
分页控件需要知道总页数，就得知道总记录数。最稳妥方式是单独执行一次 COUNT(*) 查询——虽然多一次 IO，但语义清晰、结果准确。
有人尝试用 SQL_CALC_FOUND_ROWS（MySQL 旧特性），但它已被弃用，且在 JOIN 或复杂 WHERE 下不准；也有人想从 fetch_all() 数组长度反推，但那是取出来的条数，不是总数。
实操建议：
- 用同一条件写 COUNT 查询：
$countSql = "SELECT COUNT(*) FROM article WHERE status = 1";
- 把 COUNT 查询和主查询放在同一个事务里（非必需，但可避免中间数据变更导致页码错乱）
- 如果并发写入不频繁，可考虑加缓存（如 Redis 存
article:count），但更新文章时要同步刷新
前端分页链接怎么生成才不漏参数
分页链接不是简单拼 ?page=2，要保留原有筛选条件（比如 ?category=php&tag=oop）。硬编码会丢参数，用 http_build_query() 最稳。
示例（生成第 3 页链接）：
$params = $_GET; $params['page'] = 3; echo '?'.http_build_query($params); // 输出 ?category=php&tag=oop&page=3
容易踩的坑：
- 没 unset
page就直接改值，会导致 URL 出现page=1&page=3这种重复键（PHP 默认取最后一个，但不可靠） - 用户传了恶意参数如
?page=1&sort=up%20UNION%20SELECT%20...，虽不影响分页逻辑，但可能污染 URL 显示，建议白名单过滤键名 - SEO 场景下，避免
page=1出现在首页 URL 中（可用重写或逻辑跳过）
复杂点在于：当每页数据量动态变化、或带全文检索时，总数和偏移计算必须严格对应同一份 WHERE 条件，差一个空格都可能导致最后一页数据重复或丢失。
