MySQLi分页需手动计算OFFSET和LIMIT，正确公式为offset = (page - 1) per_page，page和per_page须校验并强转整型，COUNT()须单独查询且WHERE条件一致，输出URL参数需防XSS。
MySQLi分页必须手动计算
OFFSET
和
LIMIT
MySQLi 本身不提供“自动分页”功能，
mysqli_query()
只执行 SQL，分页逻辑全靠你写对
LIMIT offset, length
。错一个参数，第一页可能漏数据、最后一页可能报错或重复。
常见错误是把当前页码直接当
OFFSET
：比如第 3 页用
LIMIT 3, 10
—— 这实际跳过前 3 条，不是前 20 条。正确公式是：
offset = (page - 1) * per_page
。
page
必须校验为正整数，建议用
(int)$_GET['page'] ?: 1
再判断是否
> 0
per_page
建议硬编码或白名单限制（如只允许 10/20/50），避免传
?limit=999999
拖垮数据库
SQL 中
LIMIT
参数不能是变量占位符，
mysqli_prepare()
不支持动态
LIMIT
，只能拼字符串（需确保
offset
和
length
已强转为 int）
查总条数必须单独执行
COUNT(*)
查询
不能靠
mysqli_num_rows()
判断总页数——它返回的是本次
LIMIT
查询的结果行数，不是全表总数。必须先跑一条
SELECT COUNT(*) FROM ...
获取总数。
注意 WHERE 条件要完全一致（包括搜索关键词、状态过滤等），否则分页会错乱。例如列表页带
WHERE status = 1
，COUNT 查询也得带上。
立即学习
“
PHP免费学习笔记（深入）
”；
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
用
mysqli_fetch_row()
提取
COUNT(*)
结果，别用
fetch_assoc()
再取键名，多此一举
如果数据量极大（千万级），
COUNT(*)
可能变慢；可考虑缓存总数，或改用近似值（如
SHOW TABLE STATUS
的
Rows
字段，但不精确）
不要在同一个
mysqli
连接里连续执行两个查询后复用结果集，记得
mysqli_free_result()
或用不同变量存结果
分页链接里的
page
参数容易被 XSS 注入
生成页码 HTML 时，若直接把
$_GET['page']
插入
href="list.php?page=..."
，攻击者可构造
?page=1%22%3E%3Cscript%3Ealert(1)%3C/script%3E
触发 XSS。
所有输出到 HTML 的 URL 参数，必须过
htmlspecialchars()
，尤其是
page
和自定义的
search
等字段
页码数字本身用
(int)
强制转换后输出，比
intval()
更快，且天然过滤非数字
不要用
$_SERVER['REQUEST_URI']
拼接分页链接，它可能含恶意片段；应解析原始参数，重写干净 URL
用
mysqli_data_seek()
实现“游标式”分页不现实
有人想复用一次大查询结果，在内存里用
mysqli_data_seek($result, $offset)
跳转——这仅适用于未缓冲的结果集（
MYSQLI_USE_RESULT
），而默认是缓冲的（
MYSQLI_STORE_RESULT
），
data_seek()
对缓冲结果有效，但代价是把全部数据载入 PHP 内存，万一行数过万，直接 OOM。
真要优化深度分页（如第 10000 页），应该放弃
OFFSET
，改用基于索引字段的游标分页（如
WHERE id > 12345 ORDER BY id LIMIT 10
），但这需要业务主键有序且无删改空洞，和 MySQLi 无关，是 SQL 设计层面的事。
分页最易被忽略的点：没处理边界情况——比如用户手动输入
?page=0
或超最大页码，后端没重定向或返回空数组，前端就显示空白页或报错。这个逻辑必须写死，不能依赖前端传参可信。
