iris框架本身不支持分布式事务，因其仅负责http路由与请求处理，不涉及数据库连接池、rpc调用链或全局事务id管理；分布式事务需自行集成seata、saga或可靠消息等外部方案。
Iris 框架本身不提供分布式事务能力。它是一个 Go 语言的 HTTP 路由框架（类似 Gin、Echo），职责止于请求路由、中间件、JSON 序列化等，iris.Application 里没有事务管理器、两阶段提交、Saga 编排或 TCC 接口。所有“分布式事务”需求必须由你自行集成外部方案，否则就是单机本地事务，跨服务调用失败时数据必然不一致。
为什么 Iris 无法直接支持分布式事务
根本原因在于：分布式事务不是 Web 框架该管的事。Iris 不接触数据库连接池、不感知 RPC 调用链、不参与消息队列投递确认，更不维护全局事务 ID 或分支注册中心。它只负责把 POST /order 请求交给你的 handler 函数——之后是你要自己决定用 sql.Tx 包本地事务，还是调用 Seata 的 AT 模式客户端，或是发一条带幂等 key 的 MQ 消息。
- Iris 的
Context是无状态的，不携带跨请求/跨服务的事务上下文 - 它没有类似 Spring 的
@Transactional(propagation = Propagation.REQUIRES_NEW)注解机制 - 所有中间件（如日志、鉴权）默认不参与事务生命周期，也不会自动传播 XID
实际可行的集成路径：选一种并落地
你在 Iris 中写业务逻辑时，必须显式选择并接入一个分布式事务方案。没有银弹，只有取舍：
-
可靠消息 + 最终一致性：在 Iris handler 里先落库（本地事务），再用
amqp.Publish或kafka.Producer.WriteMessages发送事件；下游服务消费后更新自身状态，并通过重试 + 幂等表兜底。这是最常用、最可控的方式 -
Saga 模式（Choreography）：用 Iris 提供的
http.Client调用其他服务的补偿接口（如/cancel-order），自己维护 saga log 表记录每一步执行状态和重试次数 -
外部协调器（如 Seata Go 客户端）：目前 Seata 官方未发布 Go 语言 SDK，社区版
seata-golang处于实验阶段，稳定性与兼容性需严格验证，不建议生产直接用
容易踩的坑：别让 Iris 成为故障放大器
很多团队在 Iris 里写完 db.Exec("INSERT ...") 就立刻 http.Post("http://user-svc/deduct")，以为“顺序执行=事务”。结果是：
- RPC 超时或失败时，订单已插入但余额未扣，用户投诉“下单没扣钱”
- 没加幂等头（如
X-Idempotency-Key: uuid），重试导致重复扣款 - 用
context.WithTimeout控制整个 handler 超时，但 DB 事务未回滚，留下脏数据 - 把事务逻辑塞进中间件（比如想统一 start/commit），反而破坏了不同业务对事务粒度的真实需求
真正关键的不是 Iris 怎么写，而是你是否在 handler 开头就明确界定：这是一次本地事务操作，还是一个分布式事务的起点。后者意味着你得立刻引入消息队列、状态机或 Saga 协调器——Iris 只是那个发起动作的“手”，不是拿主意的“大脑”。
