ThinkPHP不支持跨库事务，因PDO连接隔离导致原子性无法保证；应采用Saga模式+幂等日志表实现最终一致性，确保状态持久化与补偿可靠。
ThinkPHP 不支持跨库事务，无论你用 Db::transaction() 还是手动 startTrans() + rollback()，只要操作的是不同 database（哪怕在同一 MySQL 实例），就无法保证原子性。这不是配置问题，也不是写法问题，而是 MySQL 协议和 ThinkPHP 架构共同决定的硬限制。
为什么 Db::connect('db1')->startTrans() 和 Db::connect('db2')->startTrans() 互不影响
每次调用 Db::connect() 都会创建一个全新的 PDO 连接实例，事务状态完全隔离：
-
Db::connect('user_db')的startTrans()只控制user_db这个连接上的语句 -
Db::connect('order_db')的startTrans()是另一个独立连接，它甚至不知道前一个事务的存在 - 两个连接各自提交时，
user_db已写入，order_db抛异常也不会触发前者回滚
常见错误现象：Db::transaction() 包裹两库写入，结果日志显示“成功”，但查数据库发现只有 user_db 有数据，order_db 空空如也——这就是典型的伪事务。
别碰 XA：MySQL 8.0+ 已弱化支持，TP 完全不封装
即使你查到 MySQL 支持 XA，也别在 TP 项目里试：
立即学习“PHP免费学习笔记（深入）”；
- TP 的
PDO封装层没有暴露xaCommit()、xaRollback()等方法，必须绕过 ORM 直接调$pdo->exec("XA START 'tx1'") - MySQL 8.0 默认关闭
xa_support，且XA RECOVER结果不可靠，prepare 后卡住无法自动清理 - PHP-FPM 下 XA 分支无法跨请求存活，意味着不能用于异步流程或分步提交
- TP 的连接池机制会干扰 XA 分支生命周期，容易导致悬挂事务堆积锁
实操中，你得自己管理每个 $pdo 实例、手写四步协议、监听 prepare 失败并人工介入 XA RECOVER——这已超出业务开发范畴。
真正能落地的补偿方案：Saga 模式 + 幂等日志表
放弃“一次全部成功”的幻想，转而接受最终一致性。核心是把跨库操作拆成可逆步骤，并持久化每一步状态：
- 先写主库（如
order_db），生成唯一order_sn，同时插入本地saga_log表，记录当前步骤为create_order、状态为pending - 再调用
user_db扣减积分，成功则更新saga_log状态为done；失败则写入错误信息，状态为failed - 后台定时任务扫描
saga_log中failed记录，按反向顺序执行补偿（如cancel_order） - 所有对外接口必须幂等：
deduct_points(order_sn, amount)要先查saga_log是否已执行，避免重复扣减
关键细节：补偿接口不能依赖新外部服务（比如再调一次微信支付），否则补偿链路本身就成了单点故障；saga_log 必须和主业务表在同一个库、同一事务内写入，否则连日志都可能丢失。
跨库操作最易被忽略的点，不是怎么“开始”，而是怎么“收尾”：没有持久化的状态记录，就没有可靠的重试和对账依据；没有幂等设计，一次网络抖动就会引发数据重复或错乱。别省这几行日志代码。
