PHP分页的$_GET参数必须过滤，因page、limit、offset直接参与SQL查询和HTML输出，未过滤将导致SQL注入、XSS、整数溢出等风险；须用filter_input()配合FILTER_VALIDATE_INT校验类型与范围，并二次检查offset防溢出。
PHP分页的 $_GET 参数为什么必须过滤
分页几乎都靠 page、limit、offset 这类 URL 参数驱动，而它们直接进 SQL 或输出到页面，不处理就等于把数据库和 HTML 渲染的入口钥匙扔在路边。SQL 注入、XSS、整数溢出、逻辑绕过——全在这几个参数上爆发。
常见错误现象：page=1%20OR%201=1 导致查出全部数据；limit=9999999 拖垮数据库；page= 在页面里执行脚本。
-
page必须是正整数，且不能为 0 或负数（page=0可能被 MySQL 当成 offset 0，但语义错误） -
limit和offset必须严格校验范围，比如后端限制最大limit=100，不能只靠前端控制 - 不要用
intval()直接转$_GET['page']—— 它对page=1abc会返回 1，看似“安全”，实则掩盖了非法输入
用 filter_input() 做类型+范围双校验
比手写 is_numeric() + intval() 更可靠：它原生支持过滤器链，一次完成类型转换、范围限制、默认值兜底。
使用场景：所有从 URL 来的分页参数，尤其是 page 和 limit。
立即学习“PHP免费学习笔记（深入）”；
参数差异：FILTER_SANITIZE_NUMBER_INT 会删掉非数字字符，但可能留空格或符号；FILTER_VALIDATE_INT 才真正做“验证”，失败返回 false，配合 options 可设上下限。
$page = filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT, [
'options' => ['default' => 1, 'min_range' => 1, 'max_range' => 10000]
]);
$limit = filter_input(INPUT_GET, 'limit', FILTER_VALIDATE_INT, [
'options' => ['default' => 20, 'min_range' => 1, 'max_range' => 100]
]);
if ($page === false || $limit === false) {
http_response_code(400);
die('Invalid pagination parameters');
}
性能 / 兼容性影响：无额外开销，PHP 5.2+ 原生支持，比正则或自定义函数更轻量、更可读。
拼 SQL 时别手动拼 OFFSET 和 LIMIT
即使 page 和 limit 已过滤，直接插进字符串仍危险——尤其当有人绕过前端、用 curl 改请求头或复用旧链接时。
错误写法："SELECT * FROM users LIMIT " . $limit . " OFFSET " . $offset —— 看似变量已过滤，但若后续逻辑误用未过滤变量，或未来重构漏掉校验，风险立刻回归。
- 优先用 PDO 预处理：
->bindValue(':limit', $limit, PDO::PARAM_INT)，MySQL 严格要求LIMIT参数必须是整数，PDO 会拒绝非 int 类型绑定 - 如果用 mysqli，
mysqli_stmt_bind_param()的i类型也能防类型污染，但注意：mysqli 不支持LIMIT ?占位符（语法错误），必须用sprintf()或拼接——此时务必确保变量来自filter_input()且未被中途修改 - 永远不要把
$_GET值直接传进ORDER BY字段名（如sort=name），那是另一类注入，需白名单校验
前端传参和后端兜底必须双向设防
很多人以为“前端加了 JS 校验 + 后端也 check 了”就万无一失，其实漏掉关键点：URL 参数可被任意篡改，前端校验纯属体验优化，后端才是唯一可信防线。
容易踩的坑：page=999999999 虽然通过了 filter_input() 的整数验证，但计算 offset = ($page - 1) * $limit 时可能溢出、超大、甚至触发 MySQL 的 max_allowed_packet 或内存耗尽。
- 算
offset前加二次检查：if ($page > 1000) { die('Page too large'); }，这个阈值应根据业务总数据量设定，不是拍脑袋 - 查询前先用
SQL_CALC_FOUND_ROWS或单独 COUNT（带相同 WHERE 条件）预估总数，若请求页码远超总页数，直接返回空或 404，别硬查 - 把最终生效的
page、limit、offset记进日志，异常值（如offset > 1000000）立即告警——很多注入尝试就是从试探边界值开始的
最麻烦的其实是组合场景：排序字段来自参数、搜索关键词未转义、分页又和缓存键耦合……这时候单点过滤不够，得在数据访问层统一收口。安全不是加一道 filter，而是让非法值根本没机会碰 SQL。
