Resty在Go微服务中应按需选用：高频HTTP调用且需统一超时、重试、鉴权、链路追踪时推荐使用；偶发请求则优先用标准库。初始化须全局复用client、设超时与重试、指定HostURL，并通过SetPreRequestHook注入traceID，重试策略需显式限定502/503/504及网络错误。
Resty 在 Go 微服务里到底该不该用？
Resty 是个好用的 HTTP 客户端封装，但它不是标准库，也不是“必须品”。微服务里要不要集成它，取决于你是否频繁写 http.Client 配置、是否需要统一超时/重试/日志/中间件，以及团队是否接受额外依赖。如果只是偶尔发几个请求，直接用 http.DefaultClient 或自建轻量封装更稳妥；一旦涉及鉴权透传、链路追踪注入、错误分类重试，Resty 的 SetPreRequestHook 和 SetRetryCondition 就值得引入。
怎么初始化 Resty client 才不踩坑？
Resty 的 resty.New() 返回的是全局可复用的 client 实例，但很多人误以为每次请求都要 new 一个——这会导致连接池失控、DNS 缓存失效、TLS 会话复用失败。正确做法是：在服务启动时初始化一次，注入到 handler 或 service 层。
- 必须调用
SetTimeout和SetRetryCount，否则默认无超时、无重试，容易拖垮下游或自身 goroutine - 务必设置
SetHostURL（如"https://api.example.com"），避免每次请求都拼完整 URL，也方便做 base path 统一管理 - 若服务跑在 Kubernetes 内，建议开启
SetAllowGetMethodWithBody(true)，某些 Istio 或 Envoy sidecar 对 GET 带 body 的请求拦截较严 - 不要用
resty.R()直接发请求——它每次都新建*resty.Request，但没复用底层 client 的 transport 和 cookie jar
如何把 traceID 注入到每个 Resty 请求头？
微服务链路追踪依赖 header 透传，比如 trace-id、span-id。Resty 提供 SetPreRequestHook，但它只对单次请求生效；要全局注入，得在 client 初始化时绑定上下文感知逻辑。
典型写法是结合 context.Context 和中间件式 hook：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
client := resty.New().
SetPreRequestHook(func(c *resty.Client, r *resty.Request) error {
if span := trace.SpanFromContext(r.Context()); span != nil {
r.SetHeaders(map[string]string{
"trace-id": span.SpanContext().TraceID().String(),
"span-id": span.SpanContext().SpanID().String(),
"x-request-id": getReqID(r.Context()),
})
}
return nil
})
注意：r.Context() 来自 Execute 时传入的 context，不是 client 自带的 context；如果没显式传，就 fallback 到 context.Background()，导致 trace 丢失。
Resty 的重试机制和 Go 标准库有何关键差异？
Resty 的 SetRetryCondition 看似灵活，但默认重试逻辑跟标准库 http.Client 的行为不一致：它默认重试所有 5xx，包括 501 Not Implemented 这种不该重试的状态码；而标准库只重试连接错误、超时、部分 5xx（如 502/503/504）。
- 务必覆盖默认重试条件，例如只重试
502、503、504和网络层错误：err != nil || resp.StatusCode() == 502 || resp.StatusCode() == 503 || resp.StatusCode() == 504 - 重试时
SetRetryWaitTime和SetRetryMaxWaitTime必须设，否则指数退避可能卡死在几毫秒级，压垮下游 - GET 请求默认可重试，POST/PUT 默认不重试——这是 Resty 的设计，但如果你的后端 API 是幂等的，可以手动放开：
SetAllowGetMethodWithBody(true)不影响重试策略，需单独控制
最易被忽略的一点：Resty 的重试发生在 Execute 内部，不会触发 SetPreRequestHook 多次——也就是说，traceID 只注入一次，后续重试用的是同一组 header。这点和手写 for-loop + sleep 重试不同，得提前想清楚幂等性和 header 生效范围。
