PDO模拟预处理不安全，因其本质是PHP客户端字符串拼接而非数据库端真正预处理，字符集不匹配、旧驱动转义缺陷或SQL上下文误用时易导致注入。
PDO模拟预处理（emulate_prepares=true）为何不安全
开启 PDO::ATTR_EMULATE_PREPARES => true 会让PHP在客户端“假装”执行预处理——它把占位符替换成转义后的值，再拼成完整SQL发给数据库。这**根本不是预处理**，只是字符串拼接的马甲，遇到边界情况（比如多字节字符、特殊编码、驱动解析差异）时，转义可能失效，导致恶意输入突破防护。
真实预处理 vs 模拟预处理的关键区别
真实预处理（emulate_prepares=false）由数据库服务端完成：SQL模板先编译，参数后绑定，数据永远不参与语法解析。模拟预处理则由PHP自己做替换，依赖 mysql_real_escape_string 类机制，而该机制在以下场景会失灵：
- MySQL连接字符集未设为
utf8mb4，且用户输入含 emoji 或某些 UTF-8 边界字节时，转义可能截断或错位 - 使用老版本 MySQL 驱动（如
mysqlnd 5.0.11之前），对\x00、\n、\r、'、"、\、Ctrl+Z的转义不完整 - 当参数本身是 SQL 关键字（如
user、order）且被用于非数据上下文（如表名、ORDER BY 字段）时，模拟模式下无法识别语义，仍会错误拼接
如何确认你用的是模拟还是真实预处理
别只看代码里有没有 prepare()，得验证执行路径。最直接的方法是开启 MySQL general log，然后执行一条带占位符的查询：
SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE';
之后查 mysql.general_log 表，如果看到日志里记录的是类似 SELECT * FROM users WHERE id = '1\' OR \'1\'=\'1' 这种已拼接的完整语句，说明你在用模拟模式；如果看到的是 SELECT * FROM users WHERE id = ? 加单独的 Execute 记录，则是真实预处理。
启用真实预处理的实操要点
仅设置 emulate_prepares=false 不够，必须配套以下三点，否则可能降级回模拟或报错：
- 连接 DSN 中显式指定字符集：
mysql:host=localhost;dbname=testdb;charset=utf8mb4，不能只靠set names - 确保 MySQL 服务端版本 ≥ 5.1.17（支持原生预处理协议），且未禁用
have_prepared_statement - 避免在
prepare()的 SQL 中混用变量名和问号占位符，例如"WHERE name = :name AND id = ?"在部分驱动下会强制 fallback 到模拟模式
真实预处理不是“开了就万事大吉”的开关，它是数据库、驱动、字符集、SQL 写法共同作用的结果。最容易被忽略的，是以为用了 prepare() 就等于安全——其实只要其中一环退回到模拟，整条链路就形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
