Hyperf 中跨多个数据库连接的事务无法真正回滚，因 MySQL/PostgreSQL 不支持跨库（尤其跨实例）分布式事务，DB::transaction() 仅作用于单个连接；替代方案为业务层补偿、状态机、消息队列实现最终一致性。
Hyperf 中跨多个数据库连接的事务无法真正回滚 —— 因为 MySQL/PostgreSQL 本身不支持跨库（尤其是跨实例）的分布式事务，Hyperf 的 DB::transaction() 仅作用于单个连接，对多库操作天然无感知。
跨库事务本质是伪事务
当你手动在两个不同连接上执行操作：
Db::connection('db1')->table('orders')->insert([...]);Db::connection('db2')->table('logs')->insert([...]);
这两个操作完全独立：各自有连接、各自有事务状态。即使你在外部包一层 try-catch，第一个成功、第二个失败时，第一个已提交，无法自动回滚。
Hyperf 的 DB::transaction() 不会、也不能跨越连接边界生效 —— 它只绑定当前连接实例。
替代方案：业务层补偿 + 显式控制
没有两阶段提交（2PC）中间件时，必须靠代码逻辑兜底：
- 先执行所有“可逆”操作（如写日志表、发消息、生成待确认记录），再集中提交关键变更
- 用状态字段标记流程阶段（
status IN ('pending', 'confirmed', 'failed')），失败后由定时任务或消息队列触发补偿 - 关键场景建议引入轻量消息队列（如 Redis Stream 或 Kafka），用“本地事务 + 发送消息”模式保证最终一致性
例如转账：先在账户库扣减余额并写入 transfer_out 表（含唯一业务ID），再通过消息通知目标服务入账；若第二步失败，靠幂等消费+重试恢复。
多库同实例？仍需谨慎
即使两个库在同一个 MySQL 实例中（如 db1.users 和 db2.orders），只要用了不同连接配置（connection('db1') / connection('db2')），就仍是两个独立连接，事务隔离。
唯一绕过方式是：强制共用同一连接对象（不推荐）：
- 不调用
connection('db1')和connection('db2')，而是用原生 PDO 手动切换 database（$pdo->exec("USE db1")） - 但这样破坏连接池抽象，丧失 Hyperf 对协程安全连接复用的保障，极易引发并发错乱
所以不建议为跨库事务牺牲架构清晰度和稳定性。
异常捕获与日志必须到位
跨库操作务必做到：
- 每个数据库调用都单独 try-catch，记录 SQL、参数、错误码、时间戳
- 用唯一 trace_id 关联所有子步骤，便于故障链路还原
- 对已成功的第一步操作，记录补偿入口（如反向 SQL 或回调 URL），避免人工介入
Hyperf 的 LoggerInterface 可结合 Context::set() 注入 trace_id，确保日志可追溯。
