CodeIgniter事务回滚方法详解

CodeIgniter 3 的事务回滚失效，往往并非数据库本身问题，而是开发者误以为事务自动生效或随意嵌套调用所致——根本原因在于未严格配对使用 `trans_start()` 和 `trans_complete()`，导致事务从未真正启动；更隐蔽的陷阱包括在条件分支中调用启停方法、混用原生数据库操作、模型层擅自开启事务破坏外层控制，以及错误依赖 `trans_status()` 进行实时状态判断。本文直击这些高频踩坑点，厘清 CI 3 单层扁平事务的本质逻辑，强调“最外层业务统一管控”这一核心原则，并指出手动回滚仅适用于校验失败等特殊场景，帮助开发者从机制层面理解为何“看起来没回滚”，实则根本没进入事务流程。

事务没回滚？检查 $this->db->trans_start() 和 $this->db->trans_complete() 是否成对出现

CodeIgniter 的事务不是自动开启的，必须显式调用 $this->db->trans_start() 启动，再用 $this->db->trans_complete() 结束并判断是否提交或回滚。漏掉任意一个，事务就失效——看起来像“没回滚”，其实是根本没进事务流程。

常见错误现象：INSERT 成功了，但后续 UPDATE 失败时数据没回滚；或者整个操作没报错，但部分写入生效了。

• $this->db->trans_start() 必须在所有数据库操作前调用，不能放在条件分支里（除非你明确知道分支必走）
• $this->db->trans_complete() 必须紧跟在所有操作之后，且只能调用一次 —— 多次调用不会报错，但第二次起无效
• 事务内不能混用原生 mysqli_query() 或 PDO 实例，否则 CI 无法感知失败

手动回滚要用 $this->db->trans_rollback()，但前提是事务已启动且未完成

CI 默认在 $this->db->trans_complete() 内部做自动判断：只要期间有任一查询失败（返回 false），就自动回滚。所以绝大多数情况下，你不需要也不应该手动调用 $this->db->trans_rollback() —— 它只在特殊场景下有用，比如你想主动放弃、或在 trans_complete() 之前提前终止。

使用场景：比如校验逻辑失败（非数据库错误），你想跳过后续 SQL 并回滚已执行的部分。

• 手动调用 $this->db->trans_rollback() 前，必须确保 $this->db->trans_status() 仍为 TRUE（即事务尚未被 trans_complete() 关闭）
• 调用后，事务状态变为已回滚，再调 $this->db->trans_complete() 不会重复执行回滚，但也不会报错
• 注意：$this->db->trans_rollback() 不会抛异常，也不会改变 PHP 执行流，你需要自己 return 或 exit

嵌套事务不支持，多层 trans_start() 会覆盖前一个

CodeIgniter 的事务是扁平的，没有真正的嵌套事务概念。连续两次调用 $this->db->trans_start() 会导致第一次的事务上下文被丢弃 —— 这意味着外层的回滚控制会失效。

典型问题：封装了数据库操作的模型方法各自调用了 trans_start()，主控制器再包一层事务，结果只有最内层生效。

• 解决方案：统一由最外层业务逻辑控制事务启停，内部模型方法不要碰 trans_start() / trans_complete()
• 如果必须复用带事务的模型方法，改用“事务感知模式”：在模型中检查 $this->db->trans_status() === FALSE 再决定是否自行启停
• CI 4 已支持更细粒度的事务控制（如 transBegin() + transCommit()），但 CI 3.x 始终是单层

$this->db->trans_status() 返回 NULL？说明事务还没开始或已经结束

这个函数不是用来“监听”事务状态的，而是配合 trans_complete() 做最终判定的。它只在 trans_start() 之后、trans_complete() 之前有意义；一旦 trans_complete() 执行完，状态就被重置为 NULL。

容易踩的坑：在 trans_complete() 后还去判断 trans_status()，结果永远是 NULL，误以为“事务失败”。

• 正确用法：只在 trans_complete() 调用后立刻检查，例如 if ($this->db->trans_status() === FALSE) { ... }
• 不要把它当成调试工具反复查 —— 它不是实时状态寄存器，只是完成阶段的快照
• 若需记录事务过程，建议用日志打点，而不是依赖该函数多次读取

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。