DTM是Kratos接入分布式事务的事实标准，通过独立部署的DTM服务以HTTP/gRPC协议协调事务，提供全局事务ID分发、状态持久化、自动补偿及幂等管理；Kratos仅需暴露幂等接口，由DTM完成Saga/TCC全流程控制，避免手动实现导致的状态不一致与事务卡死。
dtm 是 Kratos 项目中接入分布式事务最成熟、生产验证最多的方案，不是“可选之一”，而是当前事实标准。它不依赖 Kratos 内部机制做事务协调，而是通过 HTTP/gRPC 协议与独立部署的 dtm 服务通信，因此稳定性高、调试直观、跨语言兼容好。
为什么不能直接在 Kratos 里写 TCC 或 SAGA 逻辑
Kratos 本身不提供事务协调能力——它没有全局事务 ID 分发、分支状态持久化、自动补偿调度、幂等重试管理这些核心功能。你手动在 service 层写 Try/Confirm 方法，只是完成了业务逻辑切分，但一旦 Confirm 失败或网络超时，系统无法自动回滚已执行的 Try，也没有事务日志供人工干预。这不是“没写完”，而是架构层面缺失协调器。
常见错误现象：
- 本地事务提交成功，但远程服务调用失败，数据库状态不一致
- 手动实现的补偿函数被重复调用（无幂等 key 或状态校验），导致余额 double 扣减
- 服务重启后，未完成的 SAGA 步骤丢失，事务卡死
正确做法是把协调职责交给 dtm：Kratos 服务只暴露幂等的业务接口（如 TransOut、TransIn），由 dtm 负责生成 gid、记录每步执行结果、失败时按逆序调用补偿接口。
dtmgrpc.NewMsgGrpc 和 dtmgrpc.NewSagaGrpc 怎么选
二者底层都走 gRPC，但语义和适用场景完全不同：
-
dtmgrpc.NewMsgGrpc：适用于“最终一致性”要求宽松、允许短暂不一致的场景，比如发通知、更新缓存、写日志。它不保证所有分支一定成功，只保证消息至少投递一次（at-least-once）。适合对延迟敏感、失败可人工修复的流程。 -
dtmgrpc.NewSagaGrpc：适用于资金、库存等强一致性要求场景。它要求每个正向操作都配一个严格对应的补偿操作（如TransOut→TransOutCompensate），dtm会在任意一步失败时，自动触发已成功步骤的补偿链。注意：补偿操作必须是幂等且可重入的。
参数差异关键点：
-
NewMsgGrpc的Add()只传目标服务地址和请求体，不涉及补偿； -
NewSagaGrpc的Add()必须成对传入action和compensate接口路径，例如：Add("busi/TransOut", "busi/TransOutCompensate", req)； - 两者都需显式设置
WaitResult = true才会阻塞等待dtm返回整体结果，否则是异步提交。
Kratos 服务注册地址必须带 discovery:// 前缀
dtm 客户端（如 dtmgrpc）不直连 Kratos 服务的 IP:Port，而是通过服务发现协议解析目标地址。如果你在 dtm 配置里写的是 http://127.0.0.1:8000，dtm 会尝试 HTTP 请求，但 Kratos 默认不暴露裸 HTTP 端点给外部协调器——它只响应来自注册中心的发现请求。
正确配置方式（以 etcd 为例）：
- Kratos 服务启动时，注册到
discovery://localhost:2379/busi； -
dtm配置中的Target指向discovery://localhost:2379/dtmservice； - 在业务代码中，
busiServer变量必须设为"discovery://localhost:2379/busi"，而不是"http://localhost:8000"； - 确保
driver-kratos已导入：_ "github.com/dtm-labs/driver-kratos"，否则discovery://协议无法识别。
漏掉任一环，dtm 就会报错：failed to resolve service: discovery://... 或 rpc error: code = Unavailable desc = connection closed。
事务失败时日志里看不到具体哪步挂了
dtm 默认只在自己的控制台输出分支执行摘要（如 step 1 success），Kratos 服务内部的错误堆栈不会透传到 dtm 日志。这意味着当事务失败，你只看到 gid=xxx failed，却不知道是 TransOut 参数校验失败，还是数据库连接超时。
解决方法只有两个：
- 在 Kratos 的业务 handler 中，对所有可能出错的点打结构化日志，带上
gid字段（从metadata或请求 header 提取），例如：log.Info("TransOut start", "gid", gid, "user_id", req.UserId)； - 启用
dtm的详细日志模式（启动时加-l debug），它会打印每条 gRPC 调用的原始 request/response 和耗时； - 绝对不要依赖
dtm的返回错误信息做业务判断——它只告诉你“事务失败了”，具体原因必须查 Kratos 服务自身的日志流，按gid关联。
最容易被忽略的是：Kratos 服务的 gRPC server 必须开启 UnaryInterceptor 来提取并透传 gid，否则下游服务根本拿不到这个上下文标识，日志就串不了。
