PHP事务回滚怎么用？Rollback操作详解

PHP中正确使用PDO::rollback()回滚数据库事务远不止调用一行代码那么简单——它必须在beginTransaction()显式开启的事务内执行，否则会抛出“No active transaction”异常；需强制设置PDO::ERRMODE_EXCEPTION以确保错误可捕获，配合inTransaction()主动检查事务状态，尤其在PHP-FPM持久连接场景下更要防御性清理残留事务；DDL语句会隐式提交导致后续rollback失效，业务校验失败（如库存不足）也必须手动回滚，而非依赖异常；更关键的是，日志记录必须与业务变更同连接、同事务、同引擎，结构化存储前后状态，才能真正实现可追溯、可逆的操作闭环——漏掉任一环节，事务机制都将名存实亡。

PDO::rollback() 不会自动触发，必须显式调用且前提是已开启事务；没调 beginTransaction() 就直接 rollback() 会报 “There is no active transaction” 错误。

没开事务就调用 rollback() 会直接报错

这是最常踩的坑：以为只要执行了 SQL 就在事务里，其实 PDO 默认是自动提交模式。rollback() 只作用于由 beginTransaction() 显式开启的事务。未开启时调用，PDO 会抛出 PDOException，错误信息类似：

SQLSTATE[HY000]: General error: There is no active transaction

• 务必在 rollback() 前确认 $pdo->inTransaction() 返回 true（尤其在长连接或复用连接场景）
• 不要依赖脚本结束时的“自动回滚”——它不可控，且可能因连接池复用导致残留事务影响后续请求
• PHP-FPM 持久连接下，每次请求入口建议加 if ($pdo->inTransaction()) { $pdo->rollback(); } 防御性清理

PDO::ERRMODE_EXCEPTION 必须设，否则异常不会抛出

默认情况下 PDO 出错只返回 false，不抛异常，catch 捕不到，rollback() 就永远不会执行。

• 必须设置：$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)
• 不设此选项时，exec() 或 execute() 失败只返回 false，需手动检查返回值再决定是否 rollback()
• DDL 语句（如 DROP TABLE、CREATE INDEX）在 MySQL 中会隐式提交事务，之后的 rollback() 对此前 DDL 无效——这类操作不应放在业务事务中

业务逻辑失败也要主动 rollback()，不能只靠异常

不是所有失败都抛异常：库存不足、余额为负、状态校验不通过等，都是正常业务分支，但必须回滚已执行的前序变更。

• 示例：先 UPDATE products SET stock = stock - 1，再查 SELECT stock FROM products WHERE id = ?，发现更新后 stock $pdo->rollback()
• 避免把校验逻辑放在 SQL 里靠约束触发异常（比如唯一索引冲突），因为这不可控且难调试；显式查+判断更可靠
• 回滚后建议记录日志，包含 $_SERVER['REQUEST_URI']、用户 ID、失败原因，方便排查是代码缺陷还是恶意刷单

事务必须和日志写入同连接、同事务，否则“有日志无变更”

想支持“操作撤销”，得把业务变更和操作日志插入放在同一个 beginTransaction() 里。否则日志落盘但业务失败，回滚后日志成了孤儿。

• 日志表必须与业务表同库、同引擎（InnoDB），且不能走异步队列或新 PDO 实例
• 结构化日志字段至少含：operation_type、resource_id、before（JSON）、after（JSON）
• 别用 INSERT INTO logs (msg) VALUES ('xxx') 这种纯文本日志——机器无法解析还原逻辑

真正麻烦的从来不是写 rollback() 这一行，而是确保它在该执行的时候一定被执行，且执行时上下文干净、日志可逆、DDL 不混入、连接不复用错。这些点漏一个，事务就形同虚设。

以上就是《PHP事务回滚怎么用？Rollback操作详解》的详细内容，更多关于的资料请关注golang学习网公众号！