事务回滚失效主因是未正确进入事务流程或数据库引擎不支持；需确保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 对象
最容易被忽略的是：事务不是“写了就生效”，而是“连对了、启对了、没断开、引擎撑得住”四件事同时成立才行。尤其是模型里新建 DB 连接、表引擎误配、trans_start() 被条件包裹这三处，90% 的回滚失效都出在这儿。
