开启ThinkPHP调试模式后SQL报错不显示，需同时设置app_debug为true、database.deploy.strict为false，并重写Connection::throwException()记录SQL；日志需配置error级别；定位报错SQL应启用Db::listen或trace，注意TP自动处理字段名、时间函数等导致的MySQL 1054错误。
开启ThinkPHP调试模式后SQL报错不显示
默认情况下，即使 APP_DEBUG 为 true，ThinkPHP 6+ 也会在控制台或页面隐藏完整 SQL 错误（尤其是 PDO 异常堆栈），只抛出模糊的“SQLSTATE[HY000]”类提示。这不是配置失效，而是框架对异常做了封装处理。
真正起作用的是两个开关：
-
app_debug必须为true（在env或config/app.php中） -
database.deploy.strict设为false（否则部分驱动会静默吞掉底层错误） - 同时确保
think\exception\PDOException没被全局catch吞掉——检查中间件或app/exception/Handle.php是否提前拦截了数据库异常
SQL错误日志没写入runtime/log目录
ThinkPHP 的日志通道默认不记录 SQL 执行失败详情，它只记 Db::execute() 或 ->select() 抛出的异常对象，但不自动 dump $e->getPrevious()（即原始 PDOException）。
要让 SQL 错误落地成可查日志，得手动加钩子：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/event.php中监听think\db\event\AfterExecute和think\db\event\BeforeExecute，捕获失败时写日志 - 更直接的做法：重写
think\db\Connection的throwException()方法，在抛出前调用Log::error()记录$e->getSql()和$e->getParams() - 注意
log.level配置不能是notice或更高，否则error级别日志会被过滤
如何快速定位报错SQL语句本身
很多报错看着像连接失败或语法错误，实际是变量未绑定、字段名拼错、或 where 条件里用了未定义的关联模型别名。不能只看异常消息，得捞出真实执行的 SQL。
最稳的方式是临时启用查询日志：
- 在出问题的控制器方法开头加：
Db::listen(function ($sql, $time, $explain) { dump($sql); }); - 或者在
config/database.php中打开trace：设置'trace' => true，再配合Db::getLastSql()在异常捕获块里打印 - 警惕
->fetchSql(true)：它只返回 SQL 字符串，不触发执行，容易误判参数是否真能被绑定
MySQL 1054 错误（Unknown column）的ThinkPHP特有诱因
不是所有字段不存在都报 1054，ThinkPHP 自动加表前缀、自动处理软删除字段、自动转换时间字段类型，都会让 SQL 和你写的不一样。
常见翻车点：
- 使用
whereTime('create_time', '>', '2023-01-01')但create_time是字符串类型字段——TP 会强行转成FROM_UNIXTIME()函数，导致列不存在 - 模型启用了
auto_write_timestamp，但数据库字段叫created_at，而你在where里写了create_time，TP 不会帮你映射过去 - 关联查询中用了
with(['user' => function($q){ $q->field('name'); }])，但user表实际字段是user_name，TP 不做字段名映射，直接拼进 SQL 导致 1054
这类问题不会在开发环境立刻暴露，因为 SQLite 或 MySQL 低版本可能容忍函数嵌套，一上生产 MySQL 8 就崩。查的时候别只盯报错行号，先 echo Db::getLastSql(); die; 看真实语句长啥样。
