save()失败不抛异常而存错误于geterrors()，createcommand()->execute()直接抛yii\db\exception需try/catch；integrityexception处理数据约束冲突，staleobjectexception处理乐观锁失败。
数据库操作失败时，save() 和 createCommand()->execute() 怎么捕获异常
Yii 的数据库操作默认不自动抛出异常，必须显式启用 enableSchemaCache 之外的错误传播机制——关键在于连接配置里的 enableSchemaCache 不影响运行时异常，真正决定是否抛错的是 PDO 的 ATTR_ERRMODE。Yii 默认已设为 PDO::ERRMODE_EXCEPTION，所以绝大多数 SQL 错误（如字段不存在、唯一键冲突、外键拒绝）都会触发 yii\db\Exception 或其子类。
实操建议：
-
save()失败时，直接检查返回值：if (!$model->save()) { print_r($model->getErrors()); }；它不会抛异常，而是把验证失败或 DB 错误塞进模型的 errors 属性里 -
createCommand()系列（insert/update/delete）会直接抛yii\db\Exception，必须用try/catch包裹 - 不要依赖
getLastError()—— Yii 没这个方法；PDO 原生的errorInfo要从$exception->errorInfo取，比如$exception->errorInfo[1]是 MySQL 错误码 - 批量操作如
batchInsert()出错时，整个事务回滚，但只抛一个异常，不告诉你哪一行错了
yii\db\IntegrityException 和 yii\db\StaleObjectException 怎么区分处理
这两个是高频且语义明确的异常，不能笼统 catch (Exception $e) 一锅端。
常见错误现象：
-
IntegrityException：插入重复主键、违反外键约束、NOT NULL 字段插了 null —— 典型用户输入问题，适合给友好提示（如“用户名已被注册”） -
StaleObjectException：乐观锁失败（version字段不匹配），说明数据被别人改过了 —— 应该重读再试，或提示“数据已被他人修改，请刷新后重试” - 若 catch 时只写
yii\db\Exception，会吞掉这两类的业务含义，后续逻辑难判断是数据问题还是并发问题
使用场景示例：
try {
$model->save();
} catch (\yii\db\IntegrityException $e) {
if (strpos($e->getMessage(), 'Duplicate entry') !== false) {
$model->addError('username', '该用户名已被占用');
}
} catch (\yii\db\StaleObjectException $e) {
\Yii::$app->session->addFlash('warning', '数据已变更，请刷新页面重试');
}
事务中执行多条 SQL，怎么确保异常时全部回滚
很多人以为只要包在 beginTransaction() / commit() 里就万事大吉，其实漏掉一点：没在 catch 里调 rollback()，或者没 re-throw 异常，事务就可能卡在开启状态，下次请求复用连接时直接报错。
参数差异与易踩坑点：
- 别用
Yii::$app->db->transaction(function ($db) { ... });就完事 —— 它内部 try/catch 吞异常，你得手动检查返回值或加日志 - 手写事务块时，
rollback()必须放在 catch 第一行，否则后续代码出错会导致 rollback 不执行 - 如果事务里调用了其他也开事务的方法（比如某个 service 方法自己调了
beginTransaction()），嵌套事务在 MySQL 中实际不生效，得靠保存点（savepoint），Yii 不自动支持，得自己用createCommand("SAVEPOINT sp1")->execute() - 注意连接池行为：事务未 commit/rollback 就结束请求，连接归还池时 Yii 会强制 rollback，但日志里不会体现，容易误判
生产环境要不要记录 yii\db\Exception 的完整 SQL 和绑定参数
绝对不要。这是典型的安全隐患，SQL 里可能含用户输入、密码哈希、token，参数里更是明文敏感数据。
性能与兼容性影响：
-
$exception->getMessage()已含错误类型和简要描述（如“SQLSTATE[23000]: Integrity constraint violation”），够定位问题 -
$exception->errorInfo可安全记录：它是 PDO 返回的三元数组，[SQLSTATE, driver code, driver message]，不含 SQL 或参数 - 想查具体哪条 SQL 出错？在日志里打点：
\Yii::info("Executing insert into user: " . json_encode($data), 'db');，但必须确保$data已脱敏（如替换 password 字段为'***'） - 开发期可以用
yii\log\Target::export()临时加 dump，但上线前必须删掉 —— 日志文件若被拖库，就是直接送钥匙
最常被忽略的一点：即使关了 YII_DEBUG，只要没禁用 log 组件或没过滤掉 yii\db\* 分类，异常仍会进日志；而日志路径 runtime/logs 若被 Web 目录意外映射，就等于把错误细节全暴露出去。确认 runtime 目录不可通过 HTTP 访问，比写对 try/catch 更关键。
