DTM客户端初始化panic的根本原因是dtmcli.NewHTTPClient默认1秒超时，而DTM server未就绪或Docker DNS解析延迟；应显式设置Timeout为5秒并确保server健康。
DTM 客户端初始化为什么总 panic：context deadline exceeded
根本原因不是网络慢，而是 dtmcli.NewHTTPClient 初始化时默认用了 1 秒超时，而你的 DTM server 还没起来、或在 Docker 网络里有 DNS 解析延迟。本地开发尤其容易栽在这儿。
- 启动 DTM server 后，先用
curl http://localhost:36780/health确认它真能响应，再跑 Go 客户端 - 初始化客户端时显式加大超时：
dtmcli.NewHTTPClient(&dtmcli.HTTPClientOption{Timeout: 5 * time.Second}) - Docker Compose 场景下，Go 服务要等 DTM service ready，不能只靠 depends_on —— 得加 healthcheck + wait-for-it.sh 或用 Go 的重试逻辑
Saga 模式里，Confirm 和 Cancel 接口被重复调用怎么办
DTM 默认启用幂等写入（通过全局唯一 trans_id + 子事务 ID），但 Confirm/Cancel 本身必须是幂等的，DTM 不帮你做业务层去重。
- 每个 Confirm/Cancel handler 开头必须查 DB 或 Redis，确认该子事务是否已执行成功，
if exists then return nil - 不要依赖「DTM 只调一次」——网络分区、server 重启都可能触发重试，DTM 会按指数退避最多重试 10 次
- Cancel 接口别做「删订单」这种不可逆操作，改用「标记为已取消」+ TTL 清理更安全
本地调试时，DTM 控制台看不到事务日志
因为 DTM server 默认只记录 ERROR 级别日志，且 Web UI 的事务列表默认只查最近 24 小时数据。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动 DTM server 时加参数：
--log-level debug，日志里会出现saga transaction started、calling branch action等关键链路 - 控制台右上角时间范围选「全部」，或直接查数据库：
SELECT * FROM trans_global WHERE gid LIKE '%2024%' - Go 客户端提交事务后，立刻用
dtmcli.GenGid(dtmServer)生成的gid去控制台搜索，别等刷新
跨语言服务怎么接入 DTM：Python/Java 调用 Go 的分支服务
DTM 本身是 HTTP-first 设计，所有语言只要能发标准 POST 请求、处理 JSON，就能当分支服务，不需要 SDK。
- Go 分支服务暴露的 Confirm/Cancel 接口，必须接受
POST /confirm和POST /cancel，body 是 JSON，含trans_type、gid、branch_id字段 - Python 用
requests.post(url, json=payload)即可；Java 用RestTemplate，注意设 headerContent-Type: application/json - 关键陷阱：Go 分支服务的
http.HandleFunc必须用http.ServeMux注册，别用第三方 router（如 gin）——DTM 的健康检查路径/health是硬编码的，gin 默认不处理
真正卡住人的从来不是 Saga 流程图，而是 Cancel 接口没写幂等、或是 Docker 网络里 client 先于 server 启动那 2 秒。DTM 把协调逻辑收走了，但每个分支服务的健壮性得自己兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
