事务未回滚的根本原因是未正确配对使用 $this->db->trans_start() 和 $this->db->trans_complete()，导致事务未真正启动；ci 3 不支持嵌套事务，且 trans_status() 仅在 trans_complete() 后有效。
事务没回滚？检查 $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) { ... } - 不要把它当成调试工具反复查 —— 它不是实时状态寄存器，只是完成阶段的快照
- 若需记录事务过程，建议用日志打点，而不是依赖该函数多次读取
