codeigniter根本不支持分布式事务，因其事务机制仅基于单db实例，无法协调多库、跨服务或跨服务器操作；替代方案是采用最终一致性，通过幂等步骤、补偿机制和消息队列实现可靠业务流程。
CodeIgniter 本身不支持分布式事务，它只提供单数据库连接的本地事务封装。所谓“在 CI 里实现分布式事务”，本质是误用或强凑，会直接导致数据不一致。
为什么 CodeIgniter 根本不能做分布式事务
CI 的 $this->db->trans_start() 全部基于单一 DB 驱动实例，所有操作必须落在同一个 MySQL/PostgreSQL 连接上。一旦涉及多个数据库（比如 user_db 和 order_db）、跨服务（如调用另一个 HTTP 接口写日志库）、或不同服务器上的数据库，CI 就完全失去事务控制能力——它连 BEGIN 都发不到第二个库，更别说协调 COMMIT 或 ROLLBACK。
常见错误现象：
- 代码里写了两个
$this->load->database('db1')和$this->load->database('db2')，再各自调trans_start()，结果只有第一个生效，第二个是独立自动提交 - 模型中调了外部 API 写 Redis + 本地写 MySQL，事务只包住了 MySQL，API 成功但 MySQL 回滚，状态错乱
- 用 CI 模拟两阶段提交（2PC），手动发 PREPARE、WAIT、COMMIT 指令——MySQL 原生不支持跨库 2PC，报错
ERROR 1475: XAER_INVAL: Invalid XA transaction
替代方案：用业务层补偿代替“分布式事务”
真正可行的路径不是硬套 CI 事务 API，而是接受“最终一致性”，用可重试 + 补偿操作兜底：
- 所有跨库/跨服务操作拆成幂等步骤：先写主库（带 status = 'pending'），再发 MQ 或调下游，下游成功后回调更新 status = 'done'
- 加定时任务扫
status = 'pending'的记录，超时未完成则触发逆向操作（如退款、取消订单） - 关键动作加唯一业务 ID（如
order_no）和版本号（version字段），防止重复执行 - 不要在 CI 控制器里直接
curl_exec()调外部接口——改用消息队列（RabbitMQ/Kafka）解耦，失败可重投
如果非得多个数据库参与，只能降级为单点强一致
某些场景下（如分库但同机房、同 MySQL 实例），可通过 MySQL 的 FEDERATED 引擎或 8.0+ 的 CREATE DATABASE ... LOCATION（Data Catalog）把多逻辑库映射到同一物理事务域。但这要求：
- 所有表引擎必须是
InnoDB，且innodb_support_xa = ON - 不能用 CI 的
trans_start()，必须手写$this->db->query('XA START "tx1"');等原生命令 - CI 的
trans_status()和trans_complete()完全失效，需自行管理 XA 流程 - PHP 进程崩溃会导致 XA 事务卡在
PREPARED状态，需 DBA 定期清理XA RECOVER
最常被忽略的一点：哪怕你用尽所有技巧把多个数据库拉进一个事务上下文，只要其中任意一环经过网络（比如远程 MySQL、云数据库 Proxy），就无法规避网络分区导致的提交不确定性——这时候“回滚”可能已不可达，只能靠人工对账。别迷信任何框架封装的“分布式事务”字样。
