PDO预处理在PHP 8.2中仍可100%阻断SQL注入，但须禁用模拟预处理（显式设PDO::ATTR_EMULATE_PREPARES=false）、正确设置charset=utf8mb4字符集，且表名/字段名等结构化部分必须白名单校验。
PDO预处理在PHP 8.2中依然能100%阻断SQL注入，前提是禁用模拟预处理、正确设置字符集、且不混用字符串拼接。
为什么PDO::ATTR_EMULATE_PREPARES => false必须显式设置
PHP 8.2默认仍开启模拟预处理（PDO::ATTR_EMULATE_PREPARES => true），即PHP在客户端“假装”预处理，实际仍是字符串拼接后发给MySQL——这会让某些边界输入（如含二进制\0或特殊编码的字符串）绕过保护。
- 必须在
new PDO()后立即调用$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - 仅当MySQL服务器版本 ≥ 5.1.17 且启用了
PREVARE协议支持时，该设置才真正生效 - 若连接失败并报错
SQLSTATE[HY000]: General error: 2025，说明服务端不支持真实预处理，需降级兼容或升级MySQL
prepare()时命名占位符比问号更安全的两个现实原因
命名占位符（如:user_id）不只是为了可读性，在复杂场景下直接规避两类错误：
- 参数顺序错乱：多表JOIN或动态WHERE条件中，
?极易因增删条件导致execute([$a, $b, $c])与SQL中?位置错位，而:name绑定不依赖顺序 - 重复绑定失效：同一个占位符在SQL中出现多次（如
WHERE a = :id AND b > :id），用?必须传两次值，但命名占位符自动复用数组键值 - 注意：
bindValue()和bindParam()对命名占位符都支持，但bindParam()是引用绑定，若变量后续被修改，执行时取的是新值——多数情况应优先用bindValue()或直接execute([':id' => $id])
字符集不匹配会让prepare()形同虚设
即使开了真实预处理，若PDO连接未声明正确字符集，MySQL可能按latin1解析请求，导致UTF-8多字节字符（如表情符号、中文）被截断或转义异常，进而触发宽字节注入（如%df%27绕过单引号转义）。
立即学习“PHP免费学习笔记（深入）”；
- DSN中必须显式指定
charset=utf8mb4："mysql:host=localhost;dbname=testdb;charset=utf8mb4" - 不能依赖
SET NAMES utf8mb4语句，它不保证prepare阶段的字符上下文 - 验证方式：执行
$pdo->query("SELECT @@character_set_client, @@collation_connection")->fetch()，两项都应返回utf8mb4
最常被忽略的“安全假象”：预处理只保execute()参数，不保其他环节
开发者常误以为用了prepare()就万事大吉，但以下三处仍会引入注入风险：
- 表名、字段名、ORDER BY子句等无法用占位符——它们属于SQL结构，必须白名单校验或
preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', $table)严格过滤 - 动态构建的WHERE条件（如
"status = ? AND {$field} LIKE ?"）中$field若来自用户输入，直接拼接即破防 - 密码比较未用
password_verify()而用==或strcmp()，虽不属SQL注入，但配合注入结果可导致逻辑绕过
真正的根治不是只改一行prepare()，而是确认每个用户可控的字符串，是否进入了SQL语法层——只要进了，就必须走占位符；没进，就得换思路过滤。
