Go中无开箱即用分布式事务方案，需依业务选Saga、2PC或最终一致性；Outbox模式最常用且风险低，须同库事务+幂等下游+合理轮询。
分布式事务在 Go 里没有开箱即用的“标准解”
Go 标准库不提供分布式事务支持，database/sql 的 BeginTx 仅限单数据库实例。跨服务、跨库的事务必须靠外部协调或妥协一致性模型——这不是 Go 的缺陷，而是分布式系统本质决定的。
常见方案对比：Saga vs 两阶段提交（2PC）vs 最终一致性
真实项目中选型取决于业务容忍度和运维能力：
-
Saga 模式：适合长流程、异步主导场景（如下单→扣库存→发券→通知）。Go 生态有
go-saga、temporalio/temporal-go可用，但需手动编写补偿逻辑，Compensate函数漏写或幂等没做好，就会丢数据 -
2PC：理论强一致，但 Go 生态缺乏成熟、生产级的独立协调器实现；硬套
github.com/google/uuid+ 自研协调服务极易出现悬挂事务（Prepare成功后协调器宕机），且性能差、阻塞时间长 -
最终一致性 + 消息队列：最常用。用
go-redis或sarama发送可靠事件，配合本地事务表（outbox pattern）确保“发消息”和“改状态”原子提交。关键点是：必须用SELECT FOR UPDATE锁住业务行再 insert 到 outbox 表，否则可能重复发
用本地事务表（Outbox）避免双写不一致
这是目前 Go 项目落地最多、风险最低的实践。核心是把“更新 DB”和“发消息”塞进同一个数据库事务：
tx, _ := db.BeginTx(ctx, nil)
_, _ = tx.Exec("UPDATE orders SET status = ? WHERE id = ?", "paid", orderID)
_, _ = tx.Exec("INSERT INTO outbox (topic, payload) VALUES (?, ?)", "order_paid", payload)
tx.Commit()
然后由单独的轮询 goroutine（或 Debezium）读 outbox 表，调用下游 HTTP/gRPC 接口。注意：outbox 表必须和业务表同库同事务；轮询间隔不能太短（避免 DB 压力），也不能太长（影响延迟）；下游接口必须幂等，重试时用 idempotency-key 头或 DB 唯一键去重。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
别踩这些 Go 分布式事务典型坑
很多团队在初期快速上线时掉进这些坑，修复成本远高于设计阶段预防：
- 用
context.WithTimeout包裹整个跨服务流程，但没透传到每个子调用——超时只杀掉了顶层 goroutine，下游服务还在执行，形成“幽灵事务” - 把
time.Now()当全局时钟用于判断事务状态，忽略各节点时钟漂移，导致补偿逻辑误判 - 用
sync.Map或内存缓存模拟分布式锁，一扩容就失效；该用redis.SetNX或etcd.CompareAndSwap的地方写了内存方案 - 认为 “gRPC streaming + 流式事务” 能解决分布式问题——gRPC 本身不提供事务语义，stream 断连后状态无法回滚
真正难的不是写代码，是定义清楚“这笔钱到底算不算付成功”的业务边界。技术方案只是把那个边界翻译成可执行的约束条件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
