PHP如何实现分页功能_PHP实现分页功能方法【开发】

PHP分页：从核心逻辑到避坑指南

说起分页，很多开发者觉得无非就是“上一页”、“下一页”几个链接。但真要做到健壮、高效，里头的门道可不少。一个不小心，数据量上来或者参数传递出点岔子，页面可能就“罢工”了。咱们今天就把这事儿掰开揉碎了讲清楚。

PHP分页的核心逻辑是计算 offset 和 limit

首先得明确一点：分页不是靠某个神秘函数自动完成的。它的本质，是精准控制SQL查询的起始位置和返回条数。整个过程，其实就围绕着两个核心参数转：page（当前页码）和per_page（每页数量）。

关键的计算公式就一个：offset = (page - 1) * per_page。算出来的这个offset，连同per_page，一起丢给SQL语句的LIMIT offset, limit子句。听起来简单吧？但新手常在这里栽跟头。

一个典型的错误，是把page直接当成offset用。比如想查第2页，每页10条，结果写成了LIMIT 2, 10。这可就错了，实际应该跳过前10条，取接下来的10条，也就是LIMIT 10, 10。所以，参数校验是第一步，绝不能少。

• 页码过滤：对page，必须用(int)$_GET['page']或者更严谨的filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT)来处理，并且要判断它是否大于0。否则，一个负数的offset就可能引发意想不到的问题。
• 每页数量限制：per_page这个参数，建议要么在后台硬编码，要么设置一个白名单（比如只允许10、20、50）。千万别让用户随意传个99999过来，否则数据库压力可就大了。
• 总记录数查询：这里有个性能陷阱。获取总记录数，必须单独执行一个SELECT COUNT(*)查询。千万别想着先SELECT *把所有数据查出来，再用mysqli_num_rows()去数——数据量一大，内存瞬间就可能被撑爆（OOM）。

用 PDO 预处理防止 SQL 注入

安全无小事，尤其是在拼接SQL时。当我们手动处理LIMIT参数时，需要注意一个细节：PDO的预处理语句默认不支持对LIMIT子句的参数进行占位符绑定。

这意味着，offset和limit这两个值，我们必须先将其强制转换为整型，然后再拼接到SQL字符串中。不过，查询的其他条件（比如搜索关键词）依然强烈建议使用?占位符。

SELECT id, title FROM article WHERE status = ? AND title LIKE ? ORDER BY created_at DESC LIMIT ?, ?

执行时，按顺序绑定参数即可：$stmt->execute([$status, "%$keyword%", $offset, $per_page])。这里要再次强调，$offset和$per_page在传入前，必须是已经过校验的整型值。

立即学习“PHP免费学习笔记（深入）”；

• 不要使用mysql_real_escape_string（这个函数早已废弃）或者addslashes来处理数字参数。它们对整型转换无效，反而会给人一种虚假的安全感。
• 如果使用MySQLi扩展，在bind_param('sisi', $status, $keyword, $offset, $per_page)中，$offset和$per_page同样需要提前进行(int)强转。
• 另外，在一些旧版本的MySQL严格模式下，只带一个参数的LIMIT ?写法可能不被支持，保险起见，总是使用LIMIT ?, ?这种双参数形式。

生成分页 HTML 时要处理边界情况

分页的UI体验，直接影响用户操作。想象一下，如果总共有100页，你的导航栏就把1到100的数字全列出来，那页面得多长？用户体验会非常糟糕。

因此，页码导航绝不是简单地从1循环输出到总页数。真实场景下，必须做“省略”处理（例如显示成“1 … 5 6 7 … 100”），同时当前页需要高亮，首页和尾页的链接则要始终可见并可点击。

实现这个逻辑，核心变量就三个：$current_page（当前页）、$total_pages（总页数）、$max_show（最多显示几个页码按钮，比如设为5）。算法思路通常是优先保证当前页在可视范围内居中，然后再向两边扩展，如果不够，再补上首尾的页码。

• 当总页数不多（$total_pages <= $max_show）时，最简单，直接输出从1到总页数的所有链接。
• 如果总页数很多，就需要计算起始页码：$start = max(1, $current_page - floor($max_show / 2))。然后，还要检查$start + $max_show - 1是否超过了总页数，如果超过了，需要将起始页向左调整。
• “首页”和“末页”这两个链接（首页）必须存在，哪怕总页数只有1页，这符合用户的操作直觉。
• “上一页”和“下一页”的链接，在到达边界时（比如已经在第一页），需要添加disabled类或者禁用点击逻辑，避免生成类似page=0这样的无效链接。

前端传参不干净会导致跳页失败

这是分页功能里一个非常隐蔽的坑。假设用户在一个搜索页面（URL是/list.php?keyword=php&page=2）点击分页。如果你的分页链接只写了?page=3，那么点击后，keyword这个参数就丢失了，第三页查询的将是全部数据，而不是包含“php”关键词的结果。

解决方法很明确：在生成分页链接时，必须保留原始$_GET数组中除page参数外的所有其他键值对。最稳妥的方法是使用http_build_query(array_diff_key($_GET, ['page' => 0]))，这比用正则替换或者手动拼接要可靠得多。

• 避免直接操作$_SERVER['QUERY_STRING']来替换，因为它可能包含URL编码混乱或者空值，处理起来很麻烦。
• 如果你的项目使用了URL重写规则（比如链接看起来是/list/php/3这种格式），在后端解析路由时，也必须确保page参数能被正确提取，同时其他搜索参数不能丢失。
• 移动端浏览器常有缓存问题：用户点了第2页，返回后，再点第3页，浏览器可能直接加载第2页的缓存结果。一个简单的应对策略是在分页链接后加一个时间戳参数（如&t== time() ?>），或者直接设置Cache-Control: no-cache。

总而言之，分页功能看似基础，但offset越界、SQL注入、URL参数丢失、页码溢出这四点，任何一个没处理好，都可能在项目上线后某个时刻突然爆发问题。尤其是当数据量增长到百万级别时，像LIMIT 1000000, 20这样的查询，会让MySQL先扫描一百万行，然后才返回区区20条结果，性能会急剧下降。到了那个阶段，就该考虑换用游标分页（Cursor-based Pagination）等更高级的方案，而不是继续死磕传统的页码分页了。