PHP PDO区分模拟预处理与原生预处理的实现方法

PHP PDO 的模拟预处理和原生预处理，差别不在“有没有调用 prepare()”，而在参数模板最终由谁解析。将 PDO::ATTR_EMULATE_PREPARES 设为 false 时，PDO 优先使用驱动的原生预处理；设为 true 时，PDO 在客户端模拟预处理。生产连接应显式写出这个选择，并让 SQL 使用唯一占位符。

官方地址：https://www.php.net/manual/en/pdo.prepare.php

PHP PDO 两种预处理模式到底差在哪

PDO 的准备语句可以把用户输入作为参数传给 execute()，避免手工拼接和转义。原生预处理模式下，驱动会尝试和数据库协商语句；模拟模式则由 PDO 在客户端处理占位符，必要时把命名参数改写成驱动支持的形式。模拟模式的一个关键边界是：prepare() 本身不会向数据库发请求，因此 SQL 语法问题可能推迟到执行时才暴露。

连接创建时显式选择模式

不要把模式选择散落在每条查询里。把它放在连接选项中，和异常模式、默认返回方式一起固定下来；这样排查“同一条 SQL 在不同环境表现不同”时，先看连接契约即可。

 PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
];

// 示例 DSN 只表达连接方式，不把用户输入拼进 SQL。
$pdo = new PDO($dsn, $username, $password, $options);

// 使用 execute 数组传入完整值，异常交给上层事务或错误处理中止。
$statement = $pdo->prepare(
    'SELECT id, status FROM orders WHERE user_id = :user_id AND status = :status'
);
$statement->execute([
    'user_id' => $userId,
    'status' => $status,
]);
$rows = $statement->fetchAll(PDO::FETCH_ASSOC);

这里的 false 不是“自动更安全”的开关，也不是性能保证；它表达的是让驱动尝试原生预处理。若目标驱动对某类语法没有原生支持，错误应被记录并回到 SQL 兼容性处理，而不是无条件把所有连接改成模拟。

绑定参数时最容易踩的三个边界

第一，命名参数和问号参数不要在同一条模板中混用。第二，一个参数标记代表一个完整数据值，不能用 :table 绑定表名，也不能用一个参数展开 IN (...) 的多个值；需要动态结构时，应由受控白名单选择 SQL 片段，再单独绑定值。

第三，重复使用同名命名参数不要当成跨驱动契约。官方文档明确提示，除非启用模拟模式，否则同名标记可能不被允许。最稳的写法是为每个值使用不同名字：

prepare($sql);

// 参数只提供数据值；表名、列名和排序方向不能这样绑定。
$statement->execute([
    'user_id_a' => $userId,
    'user_id_b' => $userId,
]);

遇到 prepare 失败时按边界排查

先确认 PDO::ATTR_EMULATE_PREPARES 的实际配置和驱动名称，再把 SQL 缩成最小模板。若原生模式失败，检查驱动是否支持该语句、占位符风格是否符合驱动规则，以及 SQL 是否把参数放进了标识符位置。只有确认驱动原生能力不足、且客户端解析规则可控时，才考虑对该连接启用模拟；不要用它掩盖字段名拼错或 SQL 方言错误。

一个实用验收表如下：

• 模式：连接选项明确记录 true 或 false。
• 占位符：整条语句只用一种风格，每个值有唯一标记。
• 结构：动态表名、列名和排序方向来自白名单，不从请求参数直接进入 SQL。
• 错误：区分 prepare() 失败、execute() 失败和驱动不支持，不靠切换模拟模式消除异常。

常见问题

关闭模拟预处理后一定更快吗？

不一定。原生模式改变的是准备和参数处理边界，实际收益还取决于驱动、数据库和查询重复执行方式，应该以目标环境的查询指标判断。

能用 PDO 参数绑定列名吗？

不能。参数只能代表完整数据字面量；列名、表名和关键字应通过固定映射或白名单选择。

模拟模式能避免 SQL 注入吗？

参数化仍能减少手工转义风险，但前提是输入作为值绑定且 SQL 结构不由输入拼接。模拟模式不是放宽结构拼接规则的理由。