database/sql.Tx 不能跨服务使用，因其仅绑定单个数据库连接，无法感知HTTP/gRPC、Redis或另一MySQL实例的事务状态；本地Outbox表通过同一事务保障业务修改与事件发布的原子性，是稳当起点。

database/sql.Tx 不能跨服务用，这不是框架缺陷，而是设计边界——它只绑定单个数据库连接，对 HTTP/gRPC 调用、Redis 操作、另一个 MySQL 实例的事务状态完全无感。你调用 tx.Commit() 成功，不代表下游服务也成功；defer tx.Rollback() 更不会让已发出的 HTTP 请求撤回。

为什么本地事务表（Outbox）是最稳的起点

它把“改业务数据”和“发事件”塞进同一个 db.BeginTx()，靠数据库 ACID 保原子性，不依赖协调器、不挑战 Go 生态缺失的 2PC 实现能力。

• outbox 表必须和业务表在同一个数据库实例、同一个事务中；跨库或跨实例就失效
• INSERT INTO outbox 前建议先 SELECT ... FOR UPDATE 锁住对应业务行，否则高并发下可能重复发事件
• 轮询 outbox 的 goroutine 要控频（如 100ms 间隔），太密打爆 DB，太慢拖长延迟
• 下游消费端必须幂等：用 INSERT IGNORE、UPSERT，或 HTTP Idempotency-Key + 数据库唯一索引校验

Saga 模式下补偿逻辑总漏执行？重点查三件事

协同式 Saga 容易因事件丢失或消费者 crash 导致后续步骤不触发；编排式 Saga 则依赖 Orchestration 服务的可靠性。Temporal.io 是目前 Go 生态最接近“开箱即用”的选择，但它不是魔法——你仍需显式定义每步的 Execute 和 Compensate 函数。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

• Compensate 函数必须带 context.Context 并设超时，防止卡死阻塞整个流程
• 别用内存变量或 context.WithValue 传状态；Temporal 的 workflow ID + run ID 才是唯一上下文
• 如果不用 Temporal，自己实现编排器时，务必把每步状态（executing/compensating）落库，否则服务重启后无法续跑
• 正向操作与补偿操作共用同一笔 order_id，并在 saga_records 表中持久化每步状态（pending/succeeded/compensated）

TCC 的 Confirm/Cancel 总 panic 或资损？根源不在框架

典型错误是 panic: call to Confirm after Try failed 或余额多加一次，问题出在没管住三件事：状态校验、超时控制、日志表主键设计。

• Confirm() 开头必须 SELECT ... FOR UPDATE WHERE status = 'trying'，否则并发调用会误操作已 Cancel 的记录
• tx_log 表主键别用 uuid，高并发 INSERT 会成热点；推荐 (tx_id, branch_id) 联合主键 + 时间戳字段做分片依据
• Confirm 和 Cancel 的 SQL 都要加 context.WithTimeout，并透传到底层 db.ExecContext()，否则锁等待卡住整个事务链路
• 别用 time.Now().Before(expireTime) 判断 TCC 超时——节点间毫秒级时钟漂移就会导致 Cancel 被跳过；统一用 NTP 同步后的单调时钟

真正容易被忽略的是：**所有远程调用必须透传 context 超时，且每个子调用都得显式接收并使用它**。顶层 context.WithTimeout 只杀 goroutine，下游服务还在执行，就变成“幽灵事务”。