Beego的httplib是轻量链式请求构造器，底层依赖net/http；需先调用httplib.Get()创建*BeegoHTTPRequest对象，再链式调用.String()等方法发起请求，不自动编码URL、不内置重试、不支持精细transport控制。
Beego 的 httplib 不是标准库，也不是独立 HTTP 客户端，它是一个轻量、链式调用的请求构造器，底层仍走 Go 原生 net/http；直接用它发请求没问题，但别指望它替代 http.Client 的精细控制能力。
怎么初始化并发送最简 GET 请求
必须先导入包，再用 Get、Post 等函数创建请求对象，不能跳过这一步直接调用 .String()：
-
httplib.Get("https://api.example.com/users")返回的是*BeegoHTTPRequest，不是响应体 - 必须链式调用
.String()、.ToJSON(&v)或.Response()才真正发起请求 - 若 URL 含中文或特殊字符，需提前用
url.QueryEscape处理，httplib不自动编码 path - 默认 User-Agent 是
beegoServer，如需覆盖，必须在.SetHeader("User-Agent", "...")之后调用
POST 表单和 JSON 数据的区别处理
httplib 对表单（application/x-www-form-urlencoded）和 JSON（application/json）的设置方式完全不同，混用会 400：
- 发表单：用
.Param("key", "value")，它会自动设Content-Type: application/x-www-form-urlencoded - 发 JSON：先
jsonBytes, _ := json.Marshal(data)，再.Body(jsonBytes)，并手动.SetHeader("Content-Type", "application/json") -
.Param()和.Body()互斥——一旦调用了.Body()，.Param()就被忽略 - 不要对 JSON 请求还调用
.Param()，否则 body 为空且 header 冲突
超时、TLS 和重试的常见陷阱
httplib 的超时设置是 per-request 的，且连接超时和读写超时必须显式分开传；HTTPS 验证默认开启，内网测试容易卡住：
-
.SetTimeout(5*time.Second, 10*time.Second)：第一个是 dial timeout，第二个是 read/write timeout - 访问自签名 HTTPS 时，必须加
.SetTLSClientConfig(&tls.Config{InsecureSkipVerify: true})，否则报x509: certificate signed by unknown authority - 没有内置重试逻辑，
.Retry(3)是假的——源码里只是把错误重抛，并不重发请求；真要重试得自己套 for 循环 - 并发请求时，每个
httplib.Get()都新建一个http.Client实例，复用连接靠的是 Go 默认的http.DefaultTransport，不是httplib自己管理
Debug 输出和响应缓存的真实行为
.Debug(true) 只影响日志输出，不影响请求逻辑；而响应体缓存（body []byte）是幂等的，但只对同一请求对象生效：
-
req.Debug(true).String()会打印原始请求头和状态行，但不会打印响应 body（除非你额外fmt.Println(str)） - 同一个
req对象多次调用.String()不会重发请求，因为响应已缓存在req.body中；但换一个httplib.Get(...)就是全新请求 -
.Response()返回的是*http.Response，此时resp.Body已被读空，后续再resp.Body.Read()会得到 0 字节——必须用ioutil.ReadAll(resp.Body)一次性取完 - 别在 defer 中 close
resp.Body后还试图读它，Go 运行时不会报错，但读不到数据
真正麻烦的地方在于：它把简单请求包装得很顺手，但一旦涉及代理、cookie 持久化、流式响应或自定义 transport，就得切回原生 http.Client——httplib 的抽象层在这里就断了。
