事务回滚失败主因是表引擎非InnoDB、autocommit开启、隐式提交语句触发、undo日志空间不足；需先确认ENGINE=InnoDB、SET autocommit=0、避免DDL语句、检查INNODB STATUS及磁盘空间。
事务回滚失败，大概率不是代码写错了，而是底层机制没对上——PDO 不支持嵌套、MyISAM 不认事务、异常被吞掉、连接状态错乱，这四类问题占了 90% 以上的实际故障。
MySQL 表引擎不支持事务？先查 ENGINE
执行 SHOW CREATE TABLE user;，看输出里是不是写着 ENGINE=InnoDB。如果是 MyISAM 或 MEMORY，ROLLBACK 必然无效——它们压根没有事务能力。
- MyISAM 表执行
START TRANSACTION后，ROLLBACK不报错但也不起作用，所有变更已落盘 - 改表引擎：运行
ALTER TABLE user ENGINE=InnoDB;（注意备份） - 建表时显式指定：
CREATE TABLE user (...) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
try/catch 吞掉异常导致回滚未触发
事务是否回滚，取决于异常有没有“穿透”到框架或 PDO 的事务控制层。如果在 Db::transaction() 闭包内或 $pdo->beginTransaction() 后自己 try/catch 了，rollback() 就不会自动执行。
- ThinkPHP 错误写法：
try { Db::transaction(function() { ... }); } catch (\Exception $e) { ... }—— 外层 catch 拦截后，事务早已提交 - PDO 常见陷阱：
$pdo->beginTransaction(); try { $pdo->exec(...); } catch (\Exception $e) { echo $e->getMessage(); }—— 没调rollback()，也没 re-throw - 正确姿势：让异常冒泡，或确保
catch块里明确调用$pdo->rollback()并throw $e继续传播
嵌套事务在 PHP 中根本不存在
beginTransaction() 是 PDO 对 MySQL START TRANSACTION 的直通封装，而 MySQL（包括 InnoDB）原生不支持真正嵌套事务。所谓“内层事务”，只是你代码逻辑上的分层，底层仍是单层状态。
- 现象：
$pdo->beginTransaction()套着另一个$pdo->beginTransaction()，内层rollback()不影响外层 - 原因：第二次
begin实际被忽略，PDO 内部只维护一个事务标记位；MySQL 把它当作 savepoint 以外的非法操作静默处理 - 替代方案：用
SAVEPOINT手动模拟局部回滚：$pdo->exec("SAVEPOINT sp1");+$pdo->exec("ROLLBACK TO sp1"); - 更稳妥做法：把所有 DB 操作收进一个顶层事务块，靠业务变量控制分支逻辑，别依赖“事务嵌套”语义
回滚后连接可能卡死，别直接复用
ROLLBACK 只撤销 SQL 级别变更，不重置连接内部状态。遇到死锁、超时或语法错误后，连接可能残留未释放的 result set 或处于 error 状态，后续查询会抛 PDOException: SQLSTATE[HY000]: General error 或 Cannot execute queries while other unbuffered queries are active。
- 验证方式：回滚后立刻执行
$pdo->query("SELECT 1")->fetch()，失败说明连接已损坏 - 临时缓解：调用
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)确保错误不静默 - 生产建议：发生回滚后，主动断开并重建连接，或使用连接池管理器隔离异常连接
最易被忽略的一点：事务生效的前提是“同一连接 + 同一事务上下文”。跨模型、跨 Db::connect()、读写分离路由到从库，都会让 INSERT 和后续 SELECT 不在一个事务快照里——这不是回滚失败，是压根没进事务。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
