设置 pdo::attr_emulate_prepares => false 本意是启用真实预处理防注入，但在 thinkphp 5.1 中存在报错注入仍可触发、部分写法意外退化为模拟模式、mysql 低版本兼容性问题及日志调试困难等隐蔽风险。
设置 PDO::ATTR_EMULATE_PREPARES => false 本意是强制走真实预处理，防止 SQL 注入，但实际在 ThinkPHP 5.1 中容易掉进几个隐蔽坑里，不是配置错了，而是它和框架行为、数据库特性一叠加，就出问题。
报错注入仍可能触发
即使开了真实预处理，MySQL 在预编译阶段遇到非法函数（如 updatexml()、extractvalue()）仍会直接报错，并把错误内容回显出来。攻击者可借此盲注或报错注入——这不是 TP 框架没做预处理，而是数据库本身允许在 prepare 阶段报错并泄露数据。
- 这种风险与
ATTR_EMULATE_PREPARES开关无关，只取决于数据库是否支持报错注入 + 应用是否把错误信息暴露给前端 - 修复重点不在改这个参数，而在：关闭调试模式（
app_debug => false）、统一异常响应、过滤敏感字段不回显
部分写法会意外退化为模拟预处理
TP5.1 的查询构造器在某些动态场景下（比如使用字符串拼接的 whereRaw()、havingRaw() 或混合了变量的原生 SQL），即使配置了 false，PDO 也可能自动 fallback 到模拟模式，导致 Binding 日志消失，SQL 日志里只剩裸 SQL。
- 验证方式：查
runtime/log/sql.log，出现Binding: [xxx]才算真正生效；只有SQL:行说明被绕过了 - 避免写
whereRaw("id = $id")这类硬拼，改用参数绑定形式：whereRaw('id = ?', [$id])或where('id', $id)
MySQL 低版本兼容性问题
MySQL 5.5 或更早版本对真实预处理支持不完整，开启 false 后可能出现“Lost connection during query”或“Cannot execute queries while other unbuffered queries are active”等错误，尤其在事务中执行多条语句时。
- 不是 TP 问题，是 PDO + 旧 MySQL 的组合限制
- 生产环境若无法升级 MySQL，建议设为
true（即启用模拟预处理），同时严格校验所有输入、禁用whereRaw等高危方法
日志和调试变难
真实预处理下，SQL 日志里看不到最终拼好的语句，只有占位符（如 SELECT * FROM user WHERE id = ?），排查慢查询或逻辑错误时更费劲。
- 开发阶段可临时切回
true辅助定位，上线前再切回false - 配合
think\db\Connection::getLastSql()手动获取绑定后的完整 SQL（需在查询后立即调用）
