在 PHP 面试中，数据库安全几乎是必问的话题。很多候选人能说出“用 PDO 预处理可以防止 SQL 注入”，但再追问一句“为什么预处理能防注入”或者“模拟预处理有什么风险”，能答清楚的人就少了很多。这篇文章从面试实战角度出发，把 PDO 预处理的防注入原理讲透，并重点分析模拟预处理（ATTR_EMULATE_PREPARES = true）可能带来的安全隐患。
一、SQL 注入的本质
SQL 注入的核心原因是：用户输入被当作 SQL 语句的一部分来解析。
看一个典型例子：
$id = $_GET['id'];
$sql = "SELECT * FROM users WHERE id = $id";
$pdo->query($sql);
如果用户传入 1 OR 1=1，SQL 就变成了：
SELECT * FROM users WHERE id = 1 OR 1=1
数据库解析时，OR 1=1 是 SQL 语法的一部分，于是返回了全表数据。问题的根源在于：数据和指令没有分离。
二、PDO 预处理为什么能防注入
PDO 预处理的核心思想是将 SQL 语句的“结构”与“数据”分两次发送给数据库。
以原生预处理（ATTR_EMULATE_PREPARES = false）为例：
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);
执行过程分为两步：
- Prepare 阶段：将带有占位符的 SQL 模板发送给 MySQL，MySQL 对其进行语法解析、生成执行计划。此时占位符的位置已经被确定为“参数位”，不参与语法解析。
- Execute 阶段：将用户数据单独发送给 MySQL，MySQL 把数据填充到已经解析好的参数位上。
关键点在于：参数值在数据库端永远不会被当作 SQL 语法重新解析。即使你传入 1 OR 1=1，MySQL 也只会把它当作一个字符串或数值字面量来处理，不会把它拆解成 OR 逻辑运算符。这就是预处理防注入的根本原理——指令与数据彻底分离。
面试时可以这样总结：预处理防注入不是因为“转义了特殊字符”，而是因为参数绑定的数据根本不进入 SQL 解析器。
三、模拟预处理是什么
PDO 有一个重要配置：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
这是 PDO 的默认行为（在 MySQL 驱动下默认是 true）。所谓“模拟预处理”，是指 PDO 并没有真正让 MySQL 做 prepare，而是在 PHP 端模拟了这个过程：
- PDO 在 PHP 层把 SQL 模板和参数拼接到一起。
- 拼接时，PDO 会对参数做引号包裹和转义处理。
- 最终把拼接好的完整 SQL 发送给 MySQL 执行。
也就是说，模拟预处理本质上还是字符串拼接，只不过 PDO 帮你做了转义。
四、模拟预处理的安全隐患
既然 PDO 做了转义，为什么还说有隐患？主要有以下几点：
1. 字符集相关的绕过风险
在极老的 MySQL 版本或错误配置的字符集（如 GBK）下，转义函数 mysql_real_escape_string 曾出现过宽字节注入问题。虽然现代 PHP 和 MySQL 已经大幅缓解，但如果连接字符集设置不当，模拟预处理的转义仍可能被绕过。
2. 本地模拟不等于数据库端参数化
模拟预处理下，SQL 语句是先拼接再发送的。这意味着：
- 数据库端看到的是已经拼好的完整 SQL，没有“参数位”的概念。
- 一旦 PDO 的转义逻辑存在任何漏洞，或者开发者绕过了 PDO 的绑定机制（比如手动拼接），注入风险立即出现。
3. 容易被开发者误解为“绝对安全”
这是最现实的风险。很多开发者以为用了 prepare 就万无一失，于是在某些场景下放松警惕，比如：
// 错误示范：表名、字段名不能用占位符绑定
$table = $_GET['table'];
$stmt = $pdo->prepare("SELECT * FROM $table WHERE id = ?");
表名和字段名无法用占位符绑定，只能拼接。如果开发者误以为“用了 prepare 就安全”，直接把用户输入拼进表名，注入依然会发生。模拟预处理下这种拼接和普通拼接没有本质区别。
4. 类型处理的差异
模拟预处理时，PDO 默认会把所有参数当作字符串处理（除非显式指定类型）。这可能导致：
- 某些数值比较出现隐式类型转换。
LIMIT ?在某些版本下报错或行为异常。
而原生预处理下，参数类型由数据库端处理，行为更符合预期。
五、原生预处理 vs 模拟预处理对比
| 对比项 | 原生预处理 | 模拟预处理 |
|---|---|---|
| 参数发送方式 | 单独发送 | 拼接后发送 |
| 数据库端解析 | 参数不进入解析器 | 完整 SQL 进入解析器 |
| 防注入强度 | 高 | 依赖转义，存在理论风险 |
| 性能 | 可复用执行计划 | 每次都是新 SQL |
| 兼容性 | 依赖驱动支持 | 兼容性好 |
六、面试中的最佳实践回答
如果面试官问“如何安全使用 PDO”，可以这样回答：
- 关闭模拟预处理：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
]);
- 所有数据都用占位符绑定，不要手动拼接。
- 表名、字段名等无法绑定的部分，使用白名单校验，绝不直接拼接用户输入。
- 设置正确的连接字符集，如
charset=utf8mb4。 - 不要迷信 prepare，理解其原理才能正确使用。
七、总结
PDO 预处理防注入的本质是指令与数据分离：参数在数据库端不进入 SQL 解析器，因此无法改变 SQL 语义。而模拟预处理只是在 PHP 端做字符串拼接和转义，本质上仍是拼接，存在字符集绕过、开发者误用等隐患。
面试中，能把“为什么预处理能防注入”和“模拟预处理的风险”讲清楚，往往比背出“用 PDO 就安全”更能体现你对底层原理的理解。建议在实际项目中始终关闭模拟预处理，并配合白名单策略处理表名、字段名等动态部分，才能真正做到安全。
未经允许不得转载：任鹏个人博客 » PHP 面试精讲：PDO 预处理防注入原理与模拟预处理的安全隐患
