go无内置分布式事务支持，需显式实现saga等模式；saga推荐用postgresql存状态、幂等键防重试；seata-golang兼容性差，生产建议saga+消息队列最终一致性兜底。
Go 里没有内置的分布式事务支持
Go 标准库和主流运行时完全不提供两阶段提交（2PC）、XA 或 Saga 协调器这类能力。这不是遗漏，是设计取舍：Go 倾向让开发者显式选择、组合、控制分布式一致性逻辑，而不是封装一个“开箱即用但黑盒难调”的事务抽象。
这意味着你写 db.BeginTx() 只管单数据库，跨服务、跨库、跨消息队列的操作，必须自己编排状态、重试、补偿、幂等——没捷径。
用 Saga 模式实现跨服务事务最现实
Saga 是 Go 生态中最常落地的方案：把一个分布式操作拆成一系列本地事务，每个步骤有对应的补偿操作。失败时反向执行补偿，避免锁全局资源。
- 推荐用
go-stripe/saga或手写状态机，别硬套 Spring Cloud Alibaba 那套注解式 Saga——Go 没反射元编程惯性，写起来反而更啰嗦 - 关键不是“怎么定义 saga”，而是“怎么存 saga 执行状态”：用 PostgreSQL 的
saga_state表比 Redis 更可靠，尤其涉及重试和断点续跑 - 每个子步骤必须自带幂等键，比如
order_id:12345_action:charge，否则网络重试会重复扣款 - 不要在 saga 流程里调用非幂等外部 API（如发短信），先落库再异步触发，否则补偿时无法撤回
Seata-Golang 客户端踩坑最多
有人想直接对接 Java 侧 Seata，用 seata-golang 客户端。实际跑通率低，主因是协议兼容性和生命周期管理错位。
-
seata-golang目前只支持 AT 模式（自动代理 SQL），且仅适配database/sql，对gormv2+ 的 hook 注入不稳定，容易漏拦截tx.Commit() - AT 模式依赖全局锁表（
lock_table），高并发下易卡在LockConflictException，而 Go 客户端日志几乎不报具体冲突行 - Java TC（Transaction Coordinator）版本必须 ≤ 1.8，1.9+ 的 gRPC 协议变更会导致 Go 客户端连接后静默断开，现象是
GlobalSession not found但无错误日志 - 别把
seata-golang当主力方案压测，它更适合验证流程，生产建议切回 Saga + 最终一致性
消息队列兜底比事务本身更重要
无论用 Saga 还是 Seata，只要涉及异步环节（比如订单创建后发 Kafka 触发库存扣减），消息可靠性就是事务成败的天花板。
- Kafka 场景下，务必开启
enable.idempotence=true，并用syncProducer发送，否则重试可能造成重复消息，补偿逻辑扛不住 - RabbitMQ 要关掉
autoAck，用channel.Ack()手动确认，且 ACK 必须发生在本地事务提交之后（不能反过来） - 消息体里必须带完整上下文字段，比如
trace_id、source_tx_id、retry_count，否则排查MessageProcessingFailedError时只能靠猜 - 没有“消息事务”这回事——
db.Transaction和kafka.WriteMessages永远无法原子提交，只能靠后续对账或定时扫表来兜底
真正难的不是写几个 CompensateXXX() 函数，而是把超时边界、重试退避、死信归档、人工干预入口全想清楚。线上出问题时，没人看你的 Saga 流程图，只看 compensation_failed_count 指标和最后一条未处理死信的内容。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
