开APP_DEBUG和Db::listen()需配合PDO异常模式、关闭deploy、正确使用日志回调及及时获取真实SQL，否则无法定位SQL错误。
开 APP_DEBUG + Db::listen() 是定位 ThinkPHP SQL 报错最直接有效的组合，但光开这两个远远不够——很多开发者开了却还是看不到具体错误，问题出在配置层级、PDO 错误模式、日志通道或执行时机上。
为什么开了 APP_DEBUG 还看不到 SQL 错误？
ThinkPHP 默认即使 APP_DEBUG = true，也会静默吞掉 PDO 的原始错误信息，只抛出笼统的 SQLSTATE[HY000]。这不是调试没开，而是 PDO 自身处于 PDO::ERRMODE_SILENT 模式，出错只返回 false，不触发异常。
- 必须在数据库配置（
database.php）的pdo_params中显式设置：PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION - ThinkPHP 6.0+ 使用
pdo_params字段；5.x 版本可能叫params，需查对应文档 -
deploy配置必须为false：只要'deploy' => true，哪怕APP_DEBUG和debug全开也无效 - 检查
.env文件是否覆盖了配置，例如存在APP_DEPLOY_MODE=true
Db::listen() 怎么用才真正捕获到错？
Db::listen() 是注册一个回调，在每次 SQL 执行前后被调用，但它本身不打印、不记录，只是“给你一个钩子”。不配合日志写入或异常捕获，它就等于没生效。
- 正确姿势是在应用初始化阶段（如
app/common.php或服务提供者中）调用：Db::listen(function ($sql, $time, $explain) { if ($time === false) { // 表示执行失败，$sql 是完整语句，可直接记录或抛出 \think\facade\Log::error('SQL ERROR: ' . $sql); } }); - 注意：这个回调只对 Db 类发起的查询生效，不捕获原生 PDO::query() 或手动 new Connection() 的语句
- 如果用了事务且在
commit()时报错，$sql可能为空，此时要结合Db::getRealSql()在事务块内手动捞最近一条
错误现场到底该看哪条 SQL？
批量插入、关联查询、软删除等场景下，框架生成的 SQL 和你“以为的”往往差一层抽象。光看 getLastSql() 不够，它带占位符；而 getRealSql() 又容易被覆盖。
立即学习“PHP免费学习笔记（深入）”；
-
Db::getLastSql()返回类似INSERT INTO user (name, status) VALUES (?, ?)—— 用于核对字段结构是否匹配 -
Db::getRealSql()返回替换后的语句，但必须在查询后立刻调用，中间穿插任何 Db 操作都会重置它 - 更稳妥的做法：在异常捕获块里，用
try...catch (PDOException $e)直接读$e->getMessage()，里面含 MySQL 原生错误码和上下文（如1054 Unknown column 'user_name'） - 时间字段陷阱常见：传
'create_time' => time()到 DATETIME 字段，生成的是VALUES (1728976635)，MySQL 报错但提示极不直观
真正卡住人的从来不是“怎么开调试”，而是 PDO 错误模式没切、deploy 没关、日志 level 漏了 'sql'、或者在事务里晚了一步调 getRealSql()。这些点漏一个，APP_DEBUG 和 Db::listen() 就形同虚设。
