PHP不支持原生跨库分布式事务，需通过应用层实现最终一致性：①本地消息表+定时任务；②可靠MQ+幂等消费；③简化TCC模式；④优先重构规避分布式事务。
PHP 本身不支持跨库/跨服务的原生分布式事务，所谓“开启多个数据库的事务并一起提交或回滚”在 MySQL XA 外部模式下虽技术可行，但实际项目中几乎不可用——协调成本高、悬挂事务难处理、应用层需自行兜底崩溃状态。
MySQL XA 外部事务在 PHP 中基本不可落地
MySQL 自 5.0 起支持 XA，但仅限外部 XA（xa_start/xa_prepare/xa_commit），需要 PHP 应用作为事务协调者。这意味着：
- 你得自己实现两阶段提交的协调逻辑：记录 XID、跟踪各分支状态、崩溃后人工干预或定时扫描恢复
-
xa_recover返回的悬挂事务（prepared but not committed/rolled back）无法自动判断该提交还是回滚，必须结合业务上下文判断 - PHP-FPM 或 CLI 进程意外退出时，XA 事务会卡在
PREPARED状态，MySQL 不会自动清理，DBA 需手动xa rollback或xa commit - 主流 PDO 和 MySQLi 扩展对 XA 命令支持不完整；
PDO::exec("XA START 'xid'")可能成功，但后续xa_prepare很容易因连接复用、事务隔离级别或 autocommit 模式失败
本地消息表 + 定时任务是最稳的最终一致性方案
适用于订单创建 + 扣库存 + 发通知等典型跨库场景，核心是把“发消息”和“改业务数据”绑在同一个本地事务里：
- 建一张
msg_log表，字段至少含：id（主键）、msg_id（全局唯一，如 UUID）、topic（如order_created）、payload（JSON）、status（pending/sent/confirmed/failed）、created_at - 主流程中：先执行业务 SQL（如插入订单），再
INSERT INTO msg_log，两者在同一个Db::startTrans()内 —— 保证“业务成功 → 消息必落库” - 独立 CLI 脚本（非 Web 请求）每 5–30 秒扫描
status = 'pending'的记录，调用下游 HTTP 接口；成功则UPDATE msg_log SET status = 'confirmed'，失败则status = 'failed'并记录重试次数 - 下游接口必须幂等：用
msg_id作为去重键，重复请求直接返回 200，不重复执行
用 RabbitMQ/RocketMQ 替代轮询，但 PHP 层不能省掉幂等和状态管理
消息中间件只解决“消息不丢”，不解决“下游执行是否成功”。常见误区是以为发完 MQ 就万事大吉：
立即学习“PHP免费学习笔记（深入）”；
- RabbitMQ 的 publisher confirms 或 RocketMQ 的半消息机制，只能确保消息写入 Broker 成功，不代表消费者已处理
- PHP 消费者收到消息后，必须先写一条
msg_processed记录（含msg_id+status），再执行业务逻辑；成功后再更新该记录为done—— 避免进程重启导致重复消费 - 不要依赖消息体里的“重试次数”字段做终止判断；应以数据库中该
msg_id的最终状态为准，否则网络抖动+重复投递会造成状态错乱 - 死信队列不是兜底方案，而是告警信号：进入 DLQ 的消息必须人工介入或触发补偿脚本，不能静默丢弃
ThinkPHP/Laravel 等框架的“跨库事务”只是语法糖，不是分布式事务
像 Db::connect('db1')->startTrans() 和 Db::connect('db2')->startTrans() 分别开启两个事务，再分别 commit()，这本质是两个独立事务：
- 如果 db1 提交成功、db2 提交失败，db1 的变更已不可逆，没有原子性可言
- 这种写法适合“尽力而为”场景（如日志库写失败不影响主业务），但绝不能用于资金、库存等强一致要求环节
- 框架不会帮你做反向补偿；若真需要回滚 db1，你得手写
UPDATE或调用“取消订单”接口，而这又引入新的一致性问题 - 真正要规避风险，优先考虑合并库表（如把用户、订单、支付放在同一物理库不同 schema），而不是硬上跨库事务
最常被忽略的一点：分布式事务的复杂度不在代码怎么写，而在悬挂状态的检测与人工兜底路径是否清晰。上线前必须确认——当所有 PHP 进程全部崩溃、MQ 宕机、DB 主从延迟超 5 分钟时，哪张表能告诉你当前有哪些事务卡住了？它们各自该补还是该撤？这个答案必须落在数据库里，而不是文档或开发脑中。
