pdo::attr_emulate_prepares = false 是硬门槛，因默认模拟模式下prepare仅客户端字符串替换，数据库未预编译，既无法阻断宽字节等注入绕过，也丧失执行计划复用优势。
PDO预处理语句在 PHP 8.1 中既防注入又提速，前提是关掉模拟预处理、用对绑定方式、所有外部输入进占位符——三者缺一不可。只调 prepare() 不等于安全，也不等于快。
为什么 PDO::ATTR_EMULATE_PREPARES = false 是硬门槛
PHP 默认开启模拟预处理（PDO::ATTR_EMULATE_PREPARES => true），此时 prepare() 只是客户端字符串替换，数据库根本没收到预编译指令。攻击者仍可利用宽字节、多语句等绕过，性能上也失去复用执行计划的优势。
- MySQL 8.0+ 和 PHP 8.1 配合时，必须显式禁用：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - 启用后，首次
prepare()会触发服务端预编译，后续execute()复用执行计划，避免重复解析开销 - 若连接字符串里漏了
charset=utf8mb4，即使关了模拟，GBK 等宽字节下仍可能被%df' OR 1=1 --绕过
命名占位符 + bindValue() 比 execute([]) 更可控
直接传数组给 execute() 看似简洁，但类型推断依赖 PHP 运行时行为，整数字段传入字符串（如 "123"）可能触发隐式转换，某些驱动下仍存在边界风险；而 bindValue() 强制指定类型，语义清晰且稳定。
- 数字字段务必用
PDO::PARAM_INT：$stmt->bindValue(':id', $_GET['id'], PDO::PARAM_INT) - 字符串统一用
PDO::PARAM_STR，哪怕变量已是 string 类型，显式声明更可靠 - LIKE 子句通配符必须在 PHP 层加，不能拼进 SQL：
$search = '%' . $_GET['q'] . '%'; $stmt->bindValue(':q', $search)
哪些场景下预处理反而拖慢？怎么识别
预处理不是银弹。单次执行的简单查询（比如首页轮播图查一条记录），走预处理比 query() 多一次网络往返（prepare + execute），反而略慢；只有重复执行、结构固定、参数变化的语句才真正受益。
- 高频小查询（如用户登录校验、token 验证）适合预处理，尤其是配合连接池或长连接时
- 动态字段（如
ORDER BY :field）不能用占位符——字段名不是数据，必须白名单校验后拼接 - 批量插入建议用单条预处理 + 循环
execute()，而非拼 N 条 INSERT，但超千行时考虑LOAD DATA INFILE或事务包
最容易被忽略的是：预处理只保“结构与数据分离”，不保“逻辑正确”。比如 WHERE status = :status 绑定了用户传来的 "admin' -- "，只要它进了占位符、类型对、模拟关了，就安全；但如果你在 SQL 里写成 "WHERE status = '{$_POST['status']}'"，哪怕后面跟了 prepare()，也完全失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
