识别乐观锁冲突需查看OptimisticLockException或“stale object exception”错误；临时绕过可注释optimisticLock()、设version=null或用update()跳过校验；生产环境应捕获异常后reload重试；注意锁字段须为INT型，updateAll不自动参与乐观锁。
Yii模型保存时“乐观锁冲突”报错怎么识别
看到 OptimisticLockException 或错误信息里带 stale object exception，基本就是乐观锁在起作用。这不是 bug，是 Yii 为防止并发覆盖故意拦下的——比如 A 用户查出记录 version=5，B 用户也查出 version=5，A 先改完 save 成功并把 version 升到 6，B 再 save 时发现数据库里 version 已是 6，就直接拒绝。
不改代码的前提下快速绕过冲突（仅限调试或低风险场景）
如果你确认当前操作无并发风险，或只是临时修复测试环境问题，可临时关闭乐观锁校验：
- 在模型类中注释或删除
optimisticLock()方法的重写（如果存在） - 或在保存前手动重置版本字段：
$model->version = null;，前提是该字段没被设为NOT NULL - 更稳妥的做法是显式跳过锁检查：
$model->update(null, ['attribute1', 'attribute2']);，但注意这会跳过所有验证和事件，只执行 SQL UPDATE
真正健壮的解法：用 reload() + 重试逻辑
生产环境别绕，要处理。核心思路是：捕获异常 → 重新加载最新数据 → 合并变更 → 再保存。示例：
do {
try {
$model->name = 'new name';
$model->save();
break;
} catch (\yii\db\StaleObjectException $e) {
$model->reload(); // 从 DB 拉最新 version 和字段值
// 这里可选择性合并用户修改（如只保留 name 字段，其他按新值）
}
} while (true);
注意：reload() 不会触发验证，也不会重跑 afterFind，所以如果业务依赖这些钩子，得手动补。
容易被忽略的底层陷阱
乐观锁字段类型必须是整数型（INT），不能是 TIMESTAMP 或 VARCHAR；否则比较逻辑失效，看似没报错，实则锁形同虚设。另外，如果用 updateAll() 批量更新，它默认不参与乐观锁检查——哪怕你传了 version 条件，也得自己拼 where 子句，框架不会自动加 AND version = ?。
