ThinkPHP多库事务无法回滚的根本原因是MySQL单机不支持跨库事务原子性，即使同一实例，不同database也无法被一个事务统一管控。
ThinkPHP 多库事务无法回滚的根本原因
TP 默认的 Db::transaction() 只作用于当前连接（即当前数据库配置），跨库时每个 Db::connect() 实例是独立连接，事务彼此隔离，根本不在同一个事务上下文中。不是 TP 写得不好，而是 MySQL 单机不支持跨库（不同 database）的原生事务原子性——哪怕用的是同一个 MySQL 实例，USE db1 和 USE db2 的操作也无法被一个 START TRANSACTION 统一管控。
常见错误现象：Db::transaction() 里调用了两个库的写操作，第一个库成功提交，第二个库抛异常后，第一个库没回滚；或者手动用 Db::startTrans() + Db::rollback()，但只对当前连接生效，另一个库早已 commit。
- 别指望靠封装一层“多库事务函数”就能解决，本质是 MySQL 协议限制
- 如果两个库在不同 MySQL 实例上（比如分库），连 XA 都需要服务端开启并配置 xa_support=ON，TP 原生不提供 XA 接口封装
- TP 6.3+ 的
Connection类支持传入['deploy' => 1]做读写分离，但这和多库事务无关，别混淆
XA 事务在 ThinkPHP 中的可行性与硬门槛
MySQL XA 要求服务端启用 xa_support=ON（5.7+ 默认关闭），客户端需显式调用 XA START/XA END/XA PREPARE/XA COMMIT 四步协议，而 ThinkPHP 的 PDO 封装层完全不暴露 XA 相关方法，也没有 pdo->xaCommit() 这类接口。
实操上只能绕过 ORM，直接用原生 PDO 手动控制：
立即学习“PHP免费学习笔记（深入）”；
$pdo1 = Db::connect('db1')->getPdo();
$pdo2 = Db::connect('db2')->getPdo();
$pdo1->exec("XA START 'tx1'");
$pdo2->exec("XA START 'tx2'");
$pdo1->exec("INSERT INTO db1.user (name) VALUES ('a')");
$pdo2->exec("INSERT INTO db2.order (sn) VALUES ('SN001')");
$pdo1->exec("XA END 'tx1'");
$pdo2->exec("XA END 'tx2'");
$pdo1->exec("XA PREPARE 'tx1'");
$pdo2->exec("XA PREPARE 'tx2'");
// 两库都 prepare 成功后，再统一 commit
$pdo1->exec("XA COMMIT 'tx1'");
$pdo2->exec("XA COMMIT 'tx2'");
- prepare 失败时，必须人工介入执行
XA RECOVER查悬挂事务，不能自动清理 - TP 的连接池、连接复用机制会干扰 XA 分支的生命周期，建议禁用长连接或手动管理 PDO 实例
- PHP-FPM 下 XA 分支无法跨请求存在，不能用于异步或分步提交场景
TCC 补偿模式在 TP 项目里的轻量落地方式
比起强一致的 XA，TCC 更适合 TP 这类业务框架：把一个逻辑操作拆成 Try（预留）、Confirm（确认）、Cancel（释放）三阶段，由业务代码自己保证最终一致性。TP 不提供 TCC 框架，但可以靠数据库表 + 定时任务 + 状态机来实现。
典型结构：
- 建一张
tcc_transaction表，记录全局事务 ID、状态（try/confirm/cancel）、超时时间、重试次数 - 所有跨库操作前，先
INSERT INTO tcc_transaction记录事务头，状态为try -
Try阶段：往 db1 插用户、db2 插订单草稿（status=‘pending’），不直接生效 -
Confirm阶段：更新 db1 用户状态、db2 订单 status=‘success’；失败则进补偿队列 - 用 TP 的命令行指令（如
php think tcc:check）定时扫描超时try记录，触发Cancel或告警
关键点：Cancel 必须幂等，Confirm 必须可重入，所有操作都要带事务 ID 关联，否则补偿链就断了。
什么情况下该放弃“强一致”，改用本地消息表+最终一致
如果你的跨库操作只是“用户注册后发通知”“下单后扣库存”，而非“转账”这种金融级场景，XA 和 TCC 都属于过度设计。TP 生态里更现实的做法是：用本地消息表兜底，靠 MQ 或定时任务驱动下游。
例如：
- 在主库（db1）中建
msg_outbox表，字段含topic、payload、status（sending/sent/failed） - 注册事务里，用
Db::transaction()同时插入用户 + 插入msg_outbox（status=sending） - 另起一个命令行任务（
php think msg:dispatch），轮询msg_outbox中 status=sending 的记录，调用 db2 的 API 或直接执行 SQL，成功则更新 status=sent - 失败则重试（最多 3 次），再失败标为 failed 并告警人工介入
这比折腾 XA 或手写 TCC 控制器更稳定，也更容易测试和监控。真正难的从来不是怎么写代码，而是想清楚“这笔数据不立刻一致，业务到底能不能接受”。
