Hyperf中TCC的Try阶段不能只做状态标记，因其本质是资源预留而非业务执行；正确做法是用独立字段或表记录锁定量、校验可用库存并持久化上下文，Confirm/Cancel需基于业务状态双重校验幂等，同时严防悬挂与空补偿，并为协程环境适配事务隔离与超时设置。
Hyperf 微服务中用 TCC 保障数据一致性，不是“加个注解就完事”，而是必须明确每个阶段的资源边界、幂等控制点和失败回滚路径。TCC 在 Hyperf 里能跑通，不等于业务上不出错。
TCC 的 Try 阶段为什么不能只做状态标记？
Try 阶段本质是资源预留，不是业务执行。常见错误是把 tryDeductInventory 写成直接减库存（UPDATE inventory SET stock = stock - ?），这会导致 Confirm 失败后无法真正“释放”资源——因为库存已经扣了，Cancel 只能靠反向加回去，但加回去可能超限或被并发覆盖。
- 正确做法：用独立字段（如
locked_stock）或单独表（如inventory_lock）记录锁定量，原stock不变 - Try 必须校验可用库存 ≥ 请求量，且加锁需带唯一业务 ID（如订单号）防止重复 Try
- Try 成功后，必须持久化
business_id+action+params到本地事务表，供 Cancel/Confirm 查询上下文
Confirm 和 Cancel 的幂等性怎么落地？
幂等不是“加个 Redis key 判断是否存在”，而是要基于业务状态做双重防护。比如 Confirm 扣减真实库存时，如果只查 locked_stock > 0 就执行，会漏掉 Cancel 已成功但消息延迟到达的情况。
- Confirm 必须检查：
status = 'try_success'且confirmed_at IS NULL，再更新库存并设confirmed_at = NOW() - Cancel 必须检查：
status = 'try_success'且canceled_at IS NULL，再清空locked_stock并设canceled_at = NOW() - 所有 Confirm/Cancel 接口入口必须校验
BusinessActionContext中的branch_id和transaction_id，避免跨事务误操作
Hyperf 下 TCC 的事务悬挂和空补偿怎么防？
悬挂指 Try 成功但没收到 Confirm/Cancel 指令；空补偿指 Try 没执行，却收到了 Cancel 请求。这两个问题在 Hyperf 协程环境下更隐蔽，因为协程调度可能让日志写入滞后于 DB 操作。
- 悬挂防护：Try 成功后立即启动一个协程，5 秒后查
confirmed_at和canceled_at是否为空，为空则主动发告警并触发人工干预流程 - 空补偿防护：Cancel 执行前先查是否存在对应
business_id的 Try 记录；若无，则记录empty_compensation日志并跳过（不能报错，否则重试会死循环） - DTM 或 Seata 的子事务屏障能力在 Hyperf 里需手动对齐：用
redis.setex('tcc_barrier:{tx_id}:{branch_id}', 3600, 'try')标记 Try 状态，Confirm/Cancel 前先 get 对应 key
为什么 Hyperf 的协程特性会让 TCC 更难调试？
协程共享内存但不共享事务上下文，Db::connection()->beginTransaction() 在协程切换后可能丢失连接状态。很多开发者在 Try 阶段用事务包裹 DB 操作，结果 Confirm 阶段发现连接已提交或回滚，导致状态错乱。
- Try/Confirm/Cancel 必须各自开启独立事务，不能复用同一连接实例
- 禁止在 TCC 方法内使用
go启动新协程去调用其他服务——异步调用无法纳入当前分支事务生命周期 - 日志必须打全：每阶段都要记录
transaction_id、branch_id、params、db_affected_rows、redis_result，否则出问题时连哪一步卡住都定位不到
最常被忽略的一点：TCC 的 Confirm 超时阈值必须大于所有下游服务 P99 响应时间，而不是平均值。Hyperf 里默认协程超时是 30 秒，但如果你的支付网关 P99 是 42 秒，Confirm 就会提前中断，留下悬挂事务。
