CodeIgniter事务回滚操作详解

CodeIgniter 3 的事务回滚失效，往往并非代码逻辑错误，而是源于对事务生命周期的误解：事务不会自动开启，必须严格配对使用 `trans_start()` 和 `trans_complete()`，漏掉任一调用就等于根本没进入事务流程；嵌套事务不被支持、`trans_status()` 仅在完成前有效、混用原生数据库操作会绕过CI管控——这些隐性规则让“数据没回滚”实则是“事务压根没生效”。真正可靠的事务控制，关键在于由最外层业务逻辑统一掌管启停边界，模型层绝不擅自干预，同时善用 `trans_complete()` 后的 `trans_status()` 快照做最终判定，而非将其当作实时监控工具。

事务没回滚？检查 $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) { ... }
• 不要把它当成调试工具反复查 —— 它不是实时状态寄存器，只是完成阶段的快照
• 若需记录事务过程，建议用日志打点，而不是依赖该函数多次读取

事务真正的复杂点不在语法，而在于“谁来负责开启和关闭”。CI 3 的设计决定了事务边界必须由调用方严格把控，模型层一旦擅自启停，上层就失去控制权 —— 这种隐式耦合，比语法错误更难排查。

今天关于《CodeIgniter事务回滚操作详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！