CodeIgniter事务回滚操作与数据一致性教程

CodeIgniter事务回滚失效往往不是代码写错，而是踩中了“没真正进入事务流程”“表引擎非InnoDB”“多DB实例导致上下文丢失”“外部操作缺乏补偿机制”等隐蔽陷阱；本文直击实战痛点，详解trans_start()与trans_complete()的严格配对规则、InnoDB引擎强制要求、单DB实例事务绑定原理、手动回滚的前置条件及外部操作的补偿设计，帮你彻底避开90%的事务一致性翻车现场。

事务回滚没生效，八成不是代码写错了，而是根本没进事务流程，或者数据库引擎不支持。

事务没回滚？先确认 trans_start() 和 trans_complete() 成对出现

CodeIgniter 的事务不是“开启就自动生效”的。必须显式调用 $this->db->trans_start() 启动，再用 $this->db->trans_complete() 结束并触发自动判断。漏掉任意一个，整个操作就在普通连接里执行，失败了也不会回滚。

• trans_start() 必须放在所有数据库操作之前，不能包在 if 里——除非你 100% 确保分支一定走
• trans_complete() 必须紧跟在最后一条查询之后，且只能调一次；多调无效，也不报错
• 常见现象：INSERT 成功、UPDATE 失败，但 INSERT 没被撤回——大概率是 trans_start() 漏了，或写在了 UPDATE 后面

MySQL 下事务失效？检查表引擎是不是 InnoDB

MyISAM 引擎完全不支持事务，但 CodeIgniter 不会报错，ROLLBACK 语句发出去也白发，所有写操作照常落盘。

• 执行 SHOW CREATE TABLE your_table;，确认输出里有 ENGINE=InnoDB
• CI 的 trans_start()/trans_complete() 只是逻辑包装，底层依赖数据库本身能力
• SQLite 默认支持，但不支持嵌套事务；PostgreSQL 对 SAVEPOINT 敏感，CI 原生不封装，需手写 $this->db->query('SAVEPOINT sp1')

模型里调用多个 update()，结果部分没回滚？事务上下文丢了

CI 的事务状态绑定在单个 DB 实例上。如果模型内部用了 $this->load->database() 新建连接，或者没传入当前事务连接句柄，那这条 SQL 就脱离了事务控制。

• 模型方法里别自己调 trans_start() 或 trans_complete()——CI 不支持嵌套，后一次会覆盖前一次
• 要么让所有模型方法接受一个可选的 $db 参数，并统一用它执行查询
• 要么干脆不在事务里调模型，把 SQL 收拢到控制器或 service 类，全程只用同一个 $this->db 实例

想手动回滚？得在 trans_complete() 之前，且确保事务还活着

$this->db->trans_rollback() 不是万能补救键。它只在特殊场景下有用，比如校验失败想主动放弃，而不是等 trans_complete() 自动判断。

• 调用前必须检查 $this->db->trans_status() === TRUE，否则事务可能已被关闭或已提交
• 调用后不会抛异常，也不会中断 PHP 执行流，你自己得 return 或 exit，否则后续 SQL 还会继续跑
• 一旦调过 trans_off()，整个 DB 实例就退出事务模式了，再调 trans_start() 也没用，必须重实例化 DB 对象

最常被忽略的一点：事务只管数据库操作。文件写入、API 调用、缓存更新这些外部动作，CI 无法回滚——你要自己设计补偿逻辑，或者把它们挪到事务提交成功之后再做。

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