hyperf不原生支持且不推荐集成seata，因其at模式依赖java agent字节码增强、datasourceproxy代理及rootcontext上下文，php无法复用；tcc推荐使用tcc-transaction等php闭环方案，或采用本地消息表+最终一致性。
Hyperf 本身不原生支持 Seata，也**不推荐在 PHP 生态中对接 Seata**——Seata 是 Java 主导的分布式事务协调器，其 AT 模式依赖 Java Agent 字节码增强、TM/RM 的强生命周期绑定，PHP 无法复用其核心机制。强行桥接（如 HTTP 调用 Seata Server）会丢失事务上下文传播、补偿自动注册、子事务屏障等关键能力，反而引入单点故障和状态不一致风险。
为什么不能直接集成 Seata
Seata 的 AT 模式要求：
-
DataSourceProxy包裹数据库连接，PHP 的hyperf/database无对应代理层 - 全局事务 ID（
XID）需在协程上下文中透传，Hyperf 的Context与 Seata 的RootContext不兼容 - 分支事务注册、二阶段提交/回滚由 Seata Client 自动触发，PHP 客户端（如
seata-php）仅提供简单 API，不处理幂等、空回滚、悬挂等生产级问题 - Seata Server 的
undo_log表结构、解析逻辑专为 Java JDBC 设计，PHP 执行 SQL 回滚时无法安全还原语义
TCC 在 Hyperf 中的落地要点
Hyperf 社区主流方案是 tcc-transaction（适配 Hyperf 2.*），它不依赖外部协调器，所有逻辑在 PHP 进程内闭环：
- Try 阶段必须做资源预留（如冻结库存、预扣余额），并写入
tcc_transaction状态表，含trans_id、status、retry_count - Confirm/Cancel 必须幂等：用
WHERE status = 'trying'+UPDATE ... SET status = 'confirmed'原子更新，失败即跳过 - 空回滚防护：Cancel 前查
tcc_transaction，若无对应trying记录，直接返回成功（不抛异常） - 防悬挂：Try 阶段插入前先查是否存在
confirmed或canceled状态的同trans_id记录，有则拒绝执行 - 异步补偿靠
NSQ或hyperf/async-queue触发定时扫描，非实时依赖 RPC 调用
更轻量且可靠的替代方案：本地消息表 + 最终一致性
对大多数 Hyperf 业务（如订单+库存+积分），比 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做唯一索引）
真正难的不是选模式，而是每个环节的防御性编码：TCC 的 Confirm 失败后要不要自动降级为人工干预？本地消息表的消费者宕机了谁来接管？这些细节比“集成 Seata”更决定线上稳定性。
