Kratos本身不提供分布式事务能力，因其设计哲学聚焦解耦与可插拔，将跨服务一致性交由业务层或DTM等外部框架解决。
Kratos 本身不提供分布式事务能力，它默认不处理跨服务的事务一致性。这是由微服务架构本质决定的：每个服务拥有独立数据库，ACID 被拆散，Kratos 作为轻量级框架，也明确回避了“全局事务协调器”这类重组件的设计。你如果在 Kratos 项目里看到 Transaction、TwoPhaseCommit 或类似封装，基本是业务层自行补丁，不是框架原生支持。
为什么 Kratos 没有内置分布式事务？
Kratos 的设计哲学是“解耦、可插拔、专注核心传输与治理”，事务一致性属于业务边界问题，而非通信或注册中心层面的问题。官方文档和源码中均无 distributed_transaction、xa、seata 等模块集成；其 registry、transport、middleware 组件也不暴露事务上下文传播机制（如 XID 透传）。强行在 Kratos 中塞入 TCC 或 Saga 协调器，反而会破坏其轻量启动、单体友好、快速迭代的初衷。
实际项目中怎么落地？三个可行路径
你得自己选方案，Kratos 只负责把请求发出去、把响应收回来，中间怎么保证一致，它不管：
- 用最终一致性 + 补偿事务（Saga 模式）：每个服务本地事务提交后，通过 Kratos 的
client发起下一步调用或发消息；失败时触发预定义的补偿接口（如CancelOrder），需手动实现幂等、重试、超时控制；推荐搭配 RocketMQ 或 Asynq 使用，利用消息可靠投递兜底 - 本地消息表 + 定时核对：在业务库中建
outbox表，本地事务内写业务数据 + 写消息记录；再用 Kratos 启动一个独立job服务，定时扫描并投递未发送消息；适合对实时性要求不高、但强依赖 DB 一致性的场景 - 放弃跨服务事务，改用查询前置 + 状态机：比如下单不直接扣库存，而是先查
InventoryService返回可用数（HTTP/gRPC 调用），仅当足够时才发起本地订单写入；后续靠状态字段（status IN ('created', 'paid', 'shipped')）驱动流程，用 Kratos 的middleware统一校验状态合法性
容易踩的坑：别碰“伪分布式事务”封装
有些团队基于 Kratos 自研了“事务模板”，比如在 context 里塞 txId，再用中间件自动注入 X-Transaction-ID 请求头——这只能做链路追踪，完全不保证事务语义。常见错误包括：
- 误以为
metadata.Set("xid", txID)能让下游服务自动回滚：不能，下游根本没监听也没实现 - 在 HTTP 中间件里用
defer包裹db.Rollback()：这只对当前服务的本地 DB 有效，不影响其他服务 - 把 gRPC 流式调用当成事务原子性保障：gRPC 本身不提供跨请求事务，流中断后无法回退已发的前几条消息
真正难的不是代码怎么写，而是业务规则能不能接受“先成功、再补偿”或者“查够再写”。Kratos 不帮你做这个判断，它只确保你能干净地发出那一次 client.SayHello(ctx, req) 调用。
