需将pdo设为异常模式：在数据库配置中添加'pdo_attr'=>[pdo::attr_errmode=>pdo::errmode_exception]，或运行时调用$pdo->setattribute(pdo::attr_errmode,pdo::errmode_exception)，之后用try/catch捕获pdoexception，通过$e->errorinfo获取sqlstate、原生错误码及消息。
ThinkPHP 6 中 Db::getPdo() 报错后怎么拿到真实错误？
直接调用 Db::getPdo() 本身不抛异常，它只返回 PDO 实例；真出错往往在后续 SQL 执行时才暴露，但此时 Db::getLastSql() 可能为空，Db::getError() 也未必生效——因为底层没触发 ThinkPHP 的错误捕获链。
关键点：PDO 实例默认是静默模式（PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT），必须手动切到异常模式，否则错误被吞掉。
- 在数据库配置里加
'pdo_attr' => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION] - 或者运行时临时设置：
$pdo = Db::getPdo(); $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); - 之后所有 SQL 错误都会抛
PDOException，可用try/catch捕获，$e->getMessage()就是原始错误信息
为什么 Db::getError() 经常返回空？
这个方法只对 ThinkPHP 自己封装的查询（如 Db::table()->select()）有效，且依赖执行过程中是否触发了内部异常处理逻辑。一旦你绕过 ORM/Query 层直取 Db::getPdo() 并手写 prepare()/execute()，TP 就完全不感知这次操作，自然不会记录错误。
-
Db::getError()不是全局错误池，它只存最近一次 TP 原生查询的错误 - 手写 PDO 操作后，必须自己用
try/catch捕获PDOException，不能指望 TP 替你兜底 - 若需统一处理，建议封装一个带异常捕获的 PDO 查询函数，而不是反复调用
Db::getPdo()
PDOException 里哪些字段真正有用？
别只看 $e->getMessage()，它常被截断或丢失上下文。真正稳定可依赖的是三个属性：
-
$e->getCode()：返回 PDO 错误码（如HY000或具体数字），比文字描述更可靠 -
$e->errorInfo：数组，索引 1 是 SQLSTATE，索引 2 是驱动原生错误码（如 MySQL 的 1064），索引 3 是原生错误消息 -
$e->getPrevious()：有时会链到更底层异常（比如连接超时），别忽略
示例：
try {
Db::getPdo()->query('SELECT * FROM non_exist_table');
} catch (\PDOException $e) {
var_dump($e->errorInfo[1], $e->errorInfo[2], $e->errorInfo[3]);
// 输出类似：string(5) "42S02" int(1146) string(43) "Table 'db.non_exist_table' doesn't exist"
}
生产环境要不要关掉 PDO::ERRMODE_EXCEPTION？
不要。关闭它只会让错误更难定位——变成静默失败、返回 false 或空结果，连日志都留不下痕迹。真正的做法是捕获后做分级处理：
- 开发/测试环境：直接暴露完整
PDOException信息 - 生产环境：捕获后记录到日志（含
$e->errorInfo全量），前端只返回泛化提示（如“操作失败，请稍后重试”） - 注意：TP 的
think\exception\PDOException是包装类，但底层仍是原生PDOException，直接 catch 它就行，不用强转
最易被忽略的一点：PDO 实例复用时，setAttribute() 是实例级的，不是全局。每次从 Db::getPdo() 拿到的新实例，都要重新设一遍 PDO::ATTR_ERRMODE，除非你在连接池初始化阶段就统一配置好了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
