Go 的 net/http 客户端需显式配置超时、连接池与重定向等参数才生产可用：必须设 Timeout、MaxIdleConnsPerHost、IdleConnTimeout；响应体须先判 err 再 Close；认证与数据应规范设置 Header 和编码方式。
Go 的 net/http 客户端默认就足够健壮，但直接用 http.Get 或裸 &http.Client{} 容易踩超时、连接复用、重定向、Cookie 管理等坑。
为什么不能只用 http.Get
它底层调用的是默认全局 http.DefaultClient，而这个客户端：
• 没有设置超时（请求可能无限 hang 住）
• 复用连接但未限制最大空闲连接数（高并发下 fd 耗尽）
• 不控制重定向次数（可能陷入循环或被恶意跳转）
• 无法透传自定义 Header、TLS 配置或代理
如何正确初始化一个生产可用的 http.Client
关键不是“怎么写”，而是“哪些字段必须显式设”。以下是最小安全配置：
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
// 若需忽略证书校验（仅测试）
// TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
},
}• Timeout 控制整个请求生命周期（DNS + 连接 + 写 + 读 + 重定向）
• MaxIdleConnsPerHost 必须设，否则默认是 2，高并发下立刻阻塞
• IdleConnTimeout 防止后端关闭连接后客户端还傻等
立即学习“go语言免费学习笔记（深入）”；
如何安全处理响应体和错误
常见错误：忽略 resp.Body.Close() → 连接无法复用；或用 defer resp.Body.Close() 却没检查 err 是否非 nil。
- 永远先检查
err：如果client.Do()返回 error，resp可能为 nil - 只有
resp != nil且resp.Body != nil才调用Close() - 用
io.ReadAll(resp.Body)读取全部 body，别用resp.Body.Read()手动循环（容易漏读或 panic）
示例片段：
resp, err := client.Do(req)
if err != nil {
log.Printf("request failed: %v", err)
return
}
defer func() {
if resp != nil && resp.Body != nil {
resp.Body.Close()
}
}()
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
log.Printf("HTTP %d: %s", resp.StatusCode, resp.Status)
return
}
body, err := io.ReadAll(resp.Body)
if err != nil {
log.Printf("read body failed: %v", err)
return
}如何携带认证、自定义 Header 和表单数据
不要拼 URL 传 token，也不要用 url.Values 手动编码然后塞进 Body —— 该用什么方法就用什么方法：
- Bearer Token：
req.Header.Set("Authorization", "Bearer "+token) - JSON 请求：
req.Header.Set("Content-Type", "application/json")，再用json.NewEncoder(req.Body).Encode(data) - Form 表单：
data := url.Values{"username": {"foo"}, "password": {"bar"}}，然后req, _ := http.NewRequest("POST", url, strings.NewReader(data.Encode()))，并设req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
注意：http.PostForm 看似方便，但它内部用的是默认 client，不支持超时等控制，生产环境应避免。
真正难的不是发请求，而是理解每个字段在什么场景下会生效、谁负责清理资源、以及当服务端行为异常（如不按规范关连接、返回超大 body、中间件劫持重定向）时，你的 client 是否还能稳住。这些细节藏在 transport 的 timeout 组合、body 读取逻辑和 defer 的执行时机里，漏掉任意一环都可能让服务在线上缓慢泄漏连接或卡死。
