php 8.x 防sql注入仍依赖pdo预处理三要素：关闭模拟预处理（pdo::attr_emulate_prepares=false）、值位置用占位符+显式类型绑定（如pdo::param_int）、非值上下文（表名、order by等）严格白名单校验，缺一不可。
PHP 8.x 本身没有新增 SQL 注入防护机制——PDO 和 MySQLi 的预处理语句行为、安全边界、限制条件与 PHP 7.4 完全一致。所谓“新特性”，其实是旧机制在 PHP 8 环境下更严格地暴露了旧写法的漏洞，倒逼开发者必须补全三个关键环节。
必须关闭 PDO::ATTR_EMULATE_PREPARES
PHP 8 不改变默认值（仍为 true），但宽字节绕过、多字节字符集错配等问题在 PHP 8 的严格模式下更容易触发报错或行为异常，让模拟预处理的隐患无处藏身。
-
PDO::ATTR_EMULATE_PREPARES => false必须显式设置，否则prepare()+execute()仍是假预处理 - 检查是否生效：
$pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES)返回false才算成功 - MySQL 5.1.17+ 全支持原生预处理，无需兼容性妥协
数字参数绑定必须用 PDO::PARAM_INT
PHP 8 对类型推断更激进，(int) 强转后拼进 SQL 字符串（如 "id = " . (int)$_GET['id']）在某些边缘 case 下会触发 Notice 或导致浮点截断（如科学计数法 1e3），但更关键的是：它仍属字符串拼接，完全不防注入。
- 错误做法：
"SELECT * FROM users WHERE id = " . (int)$_GET['id'] - 正确做法：用占位符 + 显式类型绑定
$stmt->bindValue(1, (int)$_GET['id'], PDO::PARAM_INT) -
PDO::PARAM_INT能拦截1 OR 1=1、0x31（十六进制）、0b1（二进制）等非法数字表达式
ORDER BY / 表名 / 字段名白名单校验不可省略
PHP 8 没有放宽语法限制——ORDER BY ? 在 MySQL 中仍是语法错误，PDO 不会帮你“修”SQL。很多开发者误以为升级到 PHP 8 就自动支持动态字段，结果上线即报错或被绕过。
- 允许字段必须硬编码白名单：
$allowed_sorts = ['id', 'name', 'created_at']; - 校验逻辑要严格：
in_array($_GET['sort'] ?? '', $allowed_sorts, true) - 排序方向（
ASC/DESC）也需白名单：$_GET['order'] === 'DESC' ? 'DESC' : 'ASC' - 别用
filter_var()或正则“模糊匹配”，攻击者可传id ASC, (SELECT 1)绕过
真正容易被忽略的，是把「用了 prepare()」当成安全终点。PHP 8.x 下，只要没关模拟预处理、没对数字参数做 PDO::PARAM_INT 绑定、没对非值上下文做白名单，就等于在生产环境裸奔。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
