php pdo防注入的核心是数据与指令分离：预处理将sql结构和参数分两路发送，数据库独立解析绑定；拼接表名、字段名、order by、like未转义通配符及配置错误（如模拟预处理、字符集不匹配）均会绕过防护。
PHP PDO 安全问题的核心就一条：永远不要拼接 SQL 字符串。高频面试题看似在考语法，实则都在验证你是否真正理解“预处理语句如何阻断注入”以及“哪些操作会悄悄绕过防护”。
为什么 prepare + execute 能防注入？
PDO 的预处理不是简单地“替换字符串”。它把 SQL 模板和参数数据分两路发给数据库：SQL 结构先由数据库解析编译（此时占位符 ? 或 :name 是纯语法符号），参数值再以独立数据包传入，数据库底层用类型安全的方式绑定——字符串不会被当 SQL 语义执行。
常见误解：
- 误以为
prepare("SELECT * FROM user WHERE id = $id")加了 prepare 就安全（错！拼接发生在 prepare 前，SQL 已被污染） - 误以为
bindValue(':id', $_GET['id'], PDO::PARAM_INT)能强制转整型防注入（对数字字段有效，但无法阻止字符串字段中注入如' OR '1'='1）
这些“看着像预处理”的操作，其实不安全
以下写法看似用了 PDO，但实际失去防护能力：
立即学习“PHP免费学习笔记（深入）”；
-
表名/字段名动态拼接：
$table = $_GET['table']; $pdo->query("SELECT * FROM {$table}");—— 占位符不能用于标识符，必须白名单校验或硬编码 -
ORDER BY 后拼接字段名：
"ORDER BY ".$_GET['sort']—— 可用白名单数组校验：in_array($sort, ['name', 'created_at'], true) ? $sort : 'id' -
LIKE 模糊查询未转义通配符：
$pdo->prepare("WHERE name LIKE ?")->execute(["%{$_GET['q']}%"])—— 若用户输入%admin%，会匹配所有含“admin”的记录；应先用addcslashes($q, '%_\')并在 SQL 中写LIKE ? ESCAPE '\'
连接与配置层面的隐形风险
即使 SQL 写得再规范，PDO 配置错误也会让防护失效：
-
关闭模拟预处理（默认开启）：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)—— 否则 MySQL 在客户端模拟预处理，可能绕过服务端解析，导致某些边界情况（如多语句、特殊编码）下注入复活 -
字符集不匹配：PDO 连接时未指定
charset=utf8mb4，而 PHP 字符串用 UTF-8 编码，MySQL 用 latin1 解析，可能导致宽字节注入（如%df' OR 1=1 --） -
错误模式设为 SILENT：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT)—— 错误被吞掉，调试困难，且可能掩盖 prepare 失败导致回退到拼接逻辑
真实场景中的防御组合建议
单靠 PDO 不足以构建安全查询：
- 对用户输入做最小化信任：GET/POST 参数优先用
filter_var()校验格式（如邮箱、URL、整数） - 敏感操作（如删除、修改）必须二次确认或权限校验，不能只依赖 SQL 层过滤
- 日志中记录原始参数值（脱敏后），便于事后审计；避免在错误信息中暴露 SQL 片段或数据库结构
- 使用 Doctrine DBAL 或 Laravel Query Builder 等封装层时，确认其底层是否真正调用原生预处理，而非字符串替换
不复杂但容易忽略：安全不在某一行代码，而在整个数据流转链路中每一步是否坚持“数据与指令分离”原则。
