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免费学习笔记（深入）”；
- 用
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 或超最大页码，后端没重定向或返回空数组，前端就显示空白页或报错。这个逻辑必须写死，不能依赖前端传参可信。
