ThinkPHP 6.x 原生 SQL 在 MySQL 8.0+ 报错因 PDO 默认未启用模拟预处理，需在 database.php 中配置 PDO::ATTR_EMULATE_PREPARES => true；Db::raw() 不再支持直接拼接，应改用 whereRaw() 或 Db::query() 绑定参数；跨库迁移需避免硬编码函数，原生 SQL 注释、子查询及别名含问号易致绑定失效。
ThinkPHP 6.x 中 Db::query() 执行原生 SQL 为什么在 MySQL 8.0+ 报错
因为 TP6 默认使用的 PDO 驱动未显式设置 PDO::ATTR_EMULATE_PREPARES，而 MySQL 8.0+ 对 prepare 模式更严格，遇到含变量占位符的原生 SQL（如 SELECT * FROM user WHERE id = ?）会直接抛出 SQLSTATE[HY000]: General error: 2034。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
config/database.php的 MySQL 连接配置中，显式添加'options' => [PDO::ATTR_EMULATE_PREPARES => true] - 若用
Db::execute()执行 INSERT/UPDATE，且语句含VALUES (?, ?)占位符，也必须开 emulate，否则报错位置可能指向绑定参数失败而非 SQL 本身 - 关闭
emulate_prepared虽能提升性能，但在 TP6 原生 SQL 场景下几乎必然踩坑，不建议为这点性能牺牲兼容性
ThinkPHP 5.1 升级到 6.0 后 Db::raw() 不再生效的替换方式
Db::raw() 在 TP5.1 可直接嵌入字符串参与查询构建，但 TP6 改为只支持在 where()、field() 等链式方法中作为表达式使用，单独拼 SQL 字符串时会被自动转义。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 把原
Db::table('user')->where('status', Db::raw("FIND_IN_SET(1, extra_status)"))->select()改成whereRaw("FIND_IN_SET(1, extra_status)") - 若需动态拼接完整 SQL（如 UNION 查询），改用
Db::query($sql, $bind)，$bind必须是数组，不能传空或 null，否则 TP6 会跳过参数绑定直接执行，埋下注入风险 - TP6 的
whereRaw()不支持嵌套调用，比如whereRaw('id IN (SELECT id FROM ... )')中子查询仍需自己保证安全，框架不会递归解析
跨数据库迁移时原生 SQL 中函数写法差异（MySQL → PostgreSQL）
TP 的原生 SQL 不做方言转换，Db::query() 执行的是直连驱动的裸 SQL，所以 NOW()、CONCAT()、IFNULL() 这类函数在 PostgreSQL 下直接报错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 避免硬写数据库专属函数：用
date('Y-m-d H:i:s')替代NOW()，用 PHP 字符串拼接替代CONCAT(a,b)，用三元判断替代IFNULL(x, y) - 若必须用原生函数（如地理计算、窗口函数），通过
Db::getConfig('type')判断当前驱动，分条件拼 SQL 字符串 - TP6 的
think-sql-builder扩展可提供部分函数抽象，但仅覆盖常用场景，复杂查询仍需手动适配
原生 SQL 中绑定参数失效的三种典型场景
不是所有 ? 或 :name 都能被 TP 正确识别并绑定，尤其在字符串拼接、子查询、注释混用时容易静默失败。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- SQL 字符串里不能出现
--单行注释，会截断后续绑定；用/* */多行注释替代 - 子查询外层用
?占位，但子查询内部也用了?，TP6 只绑定外层，内层变成字面量，导致类型错误或全表扫描 - 字段别名含问号（如
SELECT count(*) as `count?`）会被误判为参数占位符，必须用反引号包裹且避免特殊符号
最麻烦的其实是混合了宏替换、环境变量和原生 SQL 的老项目——参数绑定失效往往不报错，只返回空结果或错数据，得逐层 echo SQL 字符串才能定位。这种地方，宁可多写几行 PHP 拼接，也别赌框架的解析逻辑。
