事务消息本质是“本地事务+可靠事件投递”，需确保db写成功则消息必达、下游必处理；禁用先commit后发消息，推荐本地消息表+定时扫描或temporal编排saga。
Go 微服务中“事务消息”不是数据库事务，而是“本地事务 + 可靠事件投递”的组合技，核心目标是：DB 写成功，消息一定发出去；消息发出去，下游一定能收到并处理——两者必须原子性绑定。
为什么不能先 commit 再发消息？
这是最常见也最危险的写法：tx.Commit() 成功后调用 kafkaClient.Produce()。网络抖动、进程崩溃、Kafka 不可用都会导致消息丢失，而 DB 已提交，系统进入不可逆的不一致态（比如订单已创建，但库存没扣）。
- 现象：订单服务日志显示“created”，库存服务日志无任何消费记录，对账任务每天扫出数百条“订单有、库存未扣”脏数据
- 本质：违反了“可靠性契约”——业务变更与事件通知必须共进退
- 正确思路：把“发消息”变成 DB 事务的一部分，或用独立但强耦合的机制兜住它
本地消息表 + 定时扫描是最稳的 Go 实现方案
不依赖 RocketMQ 事务消息等中间件特性的通用解法，纯 Go + PostgreSQL/MySQL 即可落地，生产环境故障率最低。
- 建一张
outbox_events表，字段至少含：id（主键）、topic、payload（JSON）、status（'pending'/'sent'/'failed'）、created_at - 业务逻辑中：在同一个
*pgx.Tx里，先INSERT INTO outbox_events，再执行业务更新（如UPDATE orders SET status = 'created'），最后tx.Commit() - 独立的
outbox-sender服务（或 goroutine）定时（如每 100ms）查SELECT * FROM outbox_events WHERE status = 'pending' LIMIT 100，逐条发 Kafka/NATS，成功后UPDATE outbox_events SET status = 'sent' - 关键细节：UPDATE 必须带
WHERE id = ? AND status = 'pending'防并发重复发送；消费者端必须幂等（用payload.id做 Redis SETNX 或 DB 唯一索引）
用 Temporal 编排 Saga 是高阶但省心的选择
当你的“事务链”超过 3 步（如：创建订单 → 预占库存 → 冻结余额 → 发券 → 推送通知），手写状态机+补偿容易漏逻辑。Temporal 能把整个流程声明式定义，自动处理重试、超时、补偿调度。
立即学习“go语言免费学习笔记（深入）”；
- 定义 Workflow：
OrderCreationWorkflow，内含CreateOrderActivity、ReserveInventoryActivity等步骤 - 每个 Activity 返回失败时，Temporal 自动按反向顺序调用对应
Cancel*Activity（需你实现） - Go SDK 天然支持：
temporal-go客户端可直接ExecuteWorkflow，无需自己维护 saga 状态表 - 注意点：Activity 函数必须是幂等的；所有 DB 操作仍要用本地事务封装；Temporal Server 本身需高可用部署（别单点）
最终一致性不是“随便异步”，而是用可验证的机制把“不一致的时间窗口”压缩到秒级，并确保这个窗口内任何故障都能被自动发现和修复。本地消息表解决“发不出”，Temporal 解决“编排乱”，两者不冲突——你甚至可以把 outbox 表作为 Temporal Activity 的输入源。最容易被忽略的是补偿操作的幂等校验，不是“调一次退款接口”就完事，得先查订单当前状态是否真的需要退，否则网络重传会引发资损。
