PDO预处理不能防住所有SQL注入，因默认模拟预处理会拼接参数，且参数绑定仅适用于值，不适用于表名、列名、ORDER BY等结构化部分，须白名单校验。
为什么PDO预处理不能直接防住所有SQL注入
不少开发者有个常见的误解，以为只要代码里用上了 PDO::prepare()，SQL注入的风险就彻底解除了。事实并非如此。关键在于，PDO默认开启的“模拟预处理”模式（PDO::ATTR_EMULATE_PREPARES = true），其工作方式是在PHP层面将参数值拼接回完整的SQL字符串，然后再发送给数据库执行。这个过程中，如果遇到某些精心构造的边界场景——比如涉及恶意编码的表名、列名或ORDER BY字段——防御机制仍然有可能被绕过。
真正能提供坚实保障的，是数据库服务端的“原生预处理”。这种机制将SQL语句的结构和传递的参数数据完全分离，服务端只解析结构模板，参数内容不会被当作代码执行。要启用它，必须显式关闭模拟模式：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);
这里有几个技术细节值得注意：
- MySQL 5.7及以上版本，以及MariaDB 10.2+，对原生预处理的语法支持（例如在LIMIT子句中使用占位符）才比较稳定。
- 连接时如果通过
set names等方式指定了charset=utf8mb4，但未在DSN连接字符串中声明，可能导致字符集降级，给“宽字节注入”这类攻击留下可乘之机。 - 将
PDO::ATTR_EMULATE_PREPARES设为false后，在调试阶段可能会遇到诸如“Invalid parameter number”的错误。这时别急着切回true，应该首先检查SQL语句中的占位符数量是否与绑定的参数严格匹配。
哪些地方根本不能用参数绑定，必须手动过滤
参数绑定机制有一个明确的适用范围：它只对SQL语句中的**值（Value）**部分有效。而对于SQL语句的结构化部分，例如表名、列名、ORDER BY字段、UNION子句等，参数绑定是完全不起作用的。看看下面这个典型的危险示例，无论怎么绑定参数，风险都依然存在：
$stmt = $pdo->prepare("SELECT * FROM users ORDER BY $unsafe_column");
处理这类动态结构，必须依靠白名单校验或安全的转义机制：
立即学习“PHP免费学习笔记（深入）”；
- 列名/表名：最稳妥的方法是使用硬编码的白名单。例如，通过
in_array($input, ['id', 'name', 'created_at'], true)进行严格匹配。 - ORDER BY 方向：对于ASC或DESC，建议只允许全大写的预定义值，即
in_array($dir, ['ASC', 'DESC'], true)，这样可以避免大小写变体（如‘aSc’）造成的意外绕过。 - 动态表名：如果业务确实需要多表动态查询，应该通过配置数组进行映射，而不是直接拼接用户输入。
- 一个重要的提醒：绝对不要使用
addslashes()或早已废弃的mysql_real_escape_string()来处理SQL结构部分。这些函数并非为此设计，无法提供可靠的安全保障。
如何验证你的PDO配置真的生效了
代码写好了，配置也设定了，但怎么确认数据库连接确实运行在原生预处理模式下呢？光看代码不够，最好能从MySQL服务端获取确凿证据。最直接的方法是在开发环境中开启MySQL的通用查询日志：
SET GLOBAL general_log = 'ON';
然后，执行一条使用了参数绑定的查询，再去查看日志文件。如果看到的是：
Prepare SELECT * FROM users WHERE id = ?
这表示是原生预处理（先准备语句，再执行）。如果看到的是：
Execute SELECT * FROM users WHERE id = '1\' OR \'1\'=\'1'
那说明参数值已经被拼接进去，PDO仍然运行在模拟模式下。
- 生产环境务必禁用general_log，以免影响性能和泄露信息。可以通过执行
SHOW VARIABLES LIKE 'ha ve_prepared_statement'来确认数据库服务端是否支持预处理语句。 - 在PHP代码中，可以用
$pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES)动态检查当前连接的配置状态。 - 注意一个潜在问题：在使用PHP-FPM等常驻进程模型时，数据库连接可能被复用。上一个请求中的代码可能会意外改写PDO连接的属性，因此最稳妥的做法是在每次初始化PDO对象时，都显式传入配置选项。
错误处理不当会暴露敏感信息，反而帮攻击者
开启 PDO::ERRMODE_EXCEPTION 是正确的做法，有利于错误捕获。但如果没有妥善处理异常，直接将异常信息输出到页面，就可能泄露完整的SQL语句、数据库表结构甚至服务器文件路径。攻击者常常会故意触发错误，以此来探测系统内部信息。
- 黄金法则：永远不要在生产环境中将
PDOException::getMessage()的内容直接展示给用户，因为其中通常包含SQL原文。 - 在记录错误日志时，可以保留
$e->getTraceAsString()等详细信息用于排查，但返回给前端的必须是泛化的友好提示，例如“请求处理失败，请稍后重试”。 - 对于登录、密码重置等关键接口，无论错误具体原因是什么（如用户名不存在或密码错误），都应该返回统一的错误信息（例如“用户名或密码错误”），避免通过差异化的错误提示泄露账号是否存在。
- 如果项目使用了Doctrine等ORM框架，需要注意其底层驱动配置。有些ORM的早期版本或特定配置下，可能默认仍使用模拟预处理，需要手动检查并关闭。
说到底，实际开发中最容易被忽略的环节，往往是对动态SQL结构部分（如ORDER BY、GROUP BY）的校验逻辑。这部分安全责任不在PDO的职责范围内，却恰恰是安全防线的高危缺口。千万别让一个未经严格白名单校验的动态排序字段，毁掉之前通过参数绑定建立起来的所有安全努力。
