Hyperf 无法支持 Seata AT 模式，因其依赖 Java Agent 和 DataSourceProxy，而 Hyperf 使用协程 PDO 无 SQL 拦截与 undo_log 能力；XID 透传、分支注册、二阶段协调等均不兼容 JVM 设计；实测出现 GlobalSession 卡在 Begin、Cancel 失效等问题。
Hyperf 无法基于 Seata 组件实现 AT 模式分布式事务——这不是配置不到位或文档没看全的问题，而是底层机制完全不兼容。
Seata AT 模式在 Hyperf 中根本跑不起来
-
Seata的 AT 模式强依赖 Java Agent 字节码增强 +DataSourceProxy代理层，而hyperf/database是纯协程驱动的 PDO 封装，没有等效的 SQL 拦截与 undo_log 自动生成能力 - 全局事务 ID（
XID）需通过RootContext在调用链中透传，Hyperf的Context与之无映射关系，也无法在协程切换、异步 I/O、HTTP/gRPC 调用中可靠携带 -
Seata Server的分支注册、二阶段指令下发、锁状态同步等行为，全部面向 JVM 生命周期设计；Hyperf进程无 TM/RM 客户端角色，仅靠 HTTP 调用模拟会丢失上下文、超时重试错乱、状态卡死
实测常见现象包括：GlobalSession 长期停留在 Begin 状态、BranchRegisterRequest 重复发送、Cancel 回调收不到、undo_log 表写入但无法被 PHP 解析还原。
tcc-transaction 是目前 Hyperf 生态唯一可用的 TCC 方案
它不依赖外部协调器，所有逻辑闭环在 PHP 层，适配 Hyperf 2.* 和协程模型：
-
Try阶段必须做资源预留（如冻结库存、预扣余额），并原子写入tcc_transaction表，含trans_id、status = 'trying'、retry_count -
Confirm/Cancel必须幂等：用WHERE status = 'trying' AND trans_id = ?+UPDATE ... SET status = 'confirmed'实现乐观锁更新 - 空回滚防护：收到
Cancel请求时，先查tcc_transaction，若无trying记录，直接返回成功（不抛异常） - 防悬挂：
Try执行前，查是否存在confirmed或canceled状态的同trans_id记录，有则拒绝执行 - 异步补偿靠
hyperf/async-queue或 NSQ 触发定时扫描，不是靠 RPC 回调驱动
注意：tcc-transaction 不自动透传上下文，跨服务调用时需手动在请求头携带 X-TCC-XID，下游用 Context::set('xid', $request->header('X-TCC-XID')) 恢复。
更推荐：本地消息表 + 最终一致性
对大多数订单、库存、积分类场景，它比 TCC 更轻、更稳、更易维护：
- 在同一个本地事务中，写业务数据 + 插入一条
outbox_message（含event_type、payload、status = 'pending'） - 用独立消费者协程（
hyperf/async-queue）轮询outbox_message，按status = 'pending'投递到 Redis Stream 或 RabbitMQ - 下游消费成功后，回调上游或直接更新
outbox_message.status = 'sent'；失败则重试 + 告警 - 关键约束：
outbox_message表必须与业务表同库同事务；下游需用message_id做唯一索引实现幂等
这个方案绕开了所有分布式事务的复杂状态机，把一致性保障下沉到存储层和队列可靠性上，反而更贴近 Hyperf 的运行实际。
真正容易被忽略的一点：无论选 TCC 还是本地消息表，事务边界必须由业务代码显式定义，不能指望框架自动识别“哪些 SQL 属于一个分布式事务”。Hyperf 没有、也不会提供类似 Spring 的 @GlobalTransactional 注解能力——那不是缺失功能，而是设计取舍。
