Resty 初始化必须设置 BaseURL 和超时，否则请求大概率失败；需配对使用 SetResult() 和 SetError() 解析响应；生产环境必须禁用 Debug 模式并接管日志。
Resty 初始化必须设置 BaseURL 和超时，否则请求大概率失败
Resty 的 resty.New() 返回的是未配置的客户端实例，默认不带 BaseURL、无超时、无重试策略。直接调用 Get() 或 Post() 会因 URL 不完整或阻塞过久而报错，常见错误是 Get "": unsupported protocol scheme "" 或 context deadline exceeded。
- BaseURL 必须在初始化时通过
SetBaseURL("https://api.example.com")设置，后续所有请求路径自动拼接（如GET /v1/users） - 务必调用
SetTimeout(10 * time.Second)，Go 默认 HTTP client 没有读写超时，网络抖动时 goroutine 可能永久挂起 - 建议同时设
SetRetryCount(2)和SetRetryWaitTime(1 * time.Second)，避免瞬时 5xx 导致上游服务误判
链式调用中 Body 和 Query 参数不能混用 SetBody 与 SetQueryParams
Resty 的链式方法看似自由，但 SetBody() 和 SetQueryParams() 作用域不同：前者影响请求体（POST/PUT），后者只拼接 URL 查询参数（GET/DELETE 也生效）。若在 POST 请求里误用 SetQueryParams() 传业务数据，后端收不到；反之，在 GET 里用 SetBody() 则会被忽略（除非手动改 method）。
- GET / DELETE 请求：只用
SetQueryParams(map[string]string{"id": "123"}) - POST / PUT 请求：结构体或 JSON 字符串走
SetBody()，URL 参数仍可用SetQueryParams()（比如分页page=2&limit=20） - 注意
SetFormData()仅用于application/x-www-form-urlencoded，和SetBody()互斥
JSON 响应反序列化要配对使用 SetResult() 和 SetError()
Resty 不自动解析响应体，Execute() 或 Get() 返回的 *resty.Response 中 Result() 和 Error() 是空接口，必须提前用 SetResult() 和 SetError() 告诉它“成功时解到哪，失败时解到哪”。否则 resp.Result().(*MyStruct) 会 panic，或者 resp.Error() 总是 nil 即使 HTTP 状态码是 400+。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
SetResult(&MyResponse{})：传指针，Resty 会把 JSON 解到该变量（无论状态码） -
SetError(&APIError{})：当响应状态码 ≥ 400 时，尝试解到此结构体，resp.Error()才非 nil - 如果 API 错误响应格式和成功一致（比如都含
code字段），可只设SetResult()，再手动判断resp.StatusCode()
生产环境必须禁用 Resty 的 Debug 模式并接管日志输出
开发时开 SetDebug(true) 看请求/响应细节很爽，但上线后每条请求都会打印完整 body（含 token、密码等敏感字段），且 stdout 输出无法收敛到统一日志系统，极易触发安全审计告警或压垮日志采集 agent。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要在 production tag 下启用
SetDebug() - 用
SetLogger()替换默认 logger，例如传入 zap.SugaredLogger 的Write()方法适配器 - 如需追踪单次请求，推荐用
SetContentLength(true)+ 自定义OnBeforeRequest()注入 trace-id 到 header，而非依赖 debug 日志
Resty 的链式语法确实简洁，但每个点背后都有明确的副作用——BaseURL 决定路径拼接逻辑，SetResult 控制内存分配时机，Debug 开关直接影响日志管道。漏掉任何一个，线上就可能出 silent fail。
