Go模块不应直接import Seata或XA驱动，因其强耦合、实验性及原生不支持；推荐用Dapr Saga、本地消息表或Temporal工作流实现低侵入跨服务事务协调。
Go 模块里不该直接 import Seata 或 XA 驱动
Go 原生不支持跨服务事务协调，database/sql 的 Begin/Commit 只作用于单个 DB 连接；强行引入 seata-golang 会带来严重耦合：它要求每个服务注册为 RM（资源管理器），依赖外部 TC（事务协调器）节点，且客户端超时配置、上下文透传稍有偏差就出现 GlobalTransaction is not active 或 timeout waiting for tc response。
- Go 驱动（如
go-sql-driver/mysql）根本不实现 XA 协议接口，调用xa_start会 panic -
seata-golang当前仍标记为实验状态，社区更新停滞，2026 年多数生产环境已弃用 - 所有“TM/RM 注册 + 分支事务提交”逻辑都侵入业务代码，无法按模块隔离
用 Dapr Saga 构建块替代 SDK 硬集成
Dapr 是目前最轻量、低侵入的协调机制——它把事务逻辑下沉到 Sidecar，Go 模块只需发 HTTP 请求或调用 dapr.Client，不用改 ORM 层、不碰事务上下文、不感知协调器拓扑。
- 启用时加
--enable-saga参数，Saga 流程由 Dapr 自动编排，失败自动触发补偿 - 每个步骤用
POST /v1.0/bindings/{name}或POST /v1.0/invoke/{app}/method/{method}调用，返回 200 即视为该步成功 - 补偿动作通过
compensate字段声明，Dapr 保证幂等重试，无需手写if err != nil { CancelOrder(...) } - 状态持久化由 Dapr 内置存储（如 Redis 或 PostgreSQL）完成，Go 模块完全无状态
事件驱动 + 本地消息表才是模块可插拔的关键
如果不用 Dapr，又想避免强依赖协调器，唯一可靠路径是把“事务协调”降级为“事件可靠投递”，靠模块自身控制边界。
- 在模块数据库内建一张
saga_events表，字段含step、payload、status（pending/processed/compensated） - 业务逻辑执行完本地事务后，
INSERT INTO saga_events再COMMIT，确保事件写入与 DB 更新原子性 - 独立协程轮询该表，对
status = 'pending'记录调用下游 HTTP/gRPC 接口，成功则UPDATE status = 'processed' - 下游失败时，不是立刻补偿，而是先
UPDATE status = 'failed'，再交由定时任务统一处理——模块间只共享表结构，不共享连接或 SDK
Temporal 工作流适合复杂编排但需接受新抽象
当 Saga 步骤超过 5 步、含人工干预或长时间等待（如审批），Temporal 的 Go SDK 提供真正可观察、可重放、可断点调试的状态机，但它不是“集成协调器”，而是替换原有调用链路。
立即学习“go语言免费学习笔记（深入）”；
- 定义 workflow 函数时，所有远程调用必须包装成
workflow.ExecuteActivity，不能直接http.Post - Activity 函数必须幂等，失败由 Temporal 自动重试，超时由
activity.RegisterWithOptions中的StartToCloseTimeout控制 - 模块升级只需改 workflow 定义和 activity 实现，Temporal Server 负责调度、持久化、补偿，Go 代码不维护状态流转逻辑
- 注意：Temporal Server 是有状态组件，部署复杂度高于 Dapr Sidecar，但比自研协调器稳定得多
context.WithTimeout 必须设在每一步调用入口，而不是整个 Saga 外层——否则某步卡死会拖垮全部流程。 
