事务回滚失效主因是未进入事务流程或数据库引擎不支持；需确保trans_start()与trans_complete()成对调用、表引擎为innodb、全程使用同一db实例，并注意外部操作需手动补偿。
事务回滚没生效，八成不是代码写错了，而是根本没进事务流程，或者数据库引擎不支持。
事务没回滚？先确认 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 无法回滚——你要自己设计补偿逻辑，或者把它们挪到事务提交成功之后再做。
