go 的 net/http 库服务端与客户端职责分离：http.client 才负责发请求，需显式构造 *http.request 并执行；默认客户端不适用于生产环境，应自定义带超时和 transport 配置的实例。
Go 的 net/http 库本身不发请求，只处理服务端逻辑；发 HTTP 请求要用 http.Client 和 http.NewRequest —— 这是初学者最常混淆的起点。
怎么用 http.Client 发 GET/POST 请求
Go 不像 Python 有 requests.get() 那样开箱即用的快捷函数，所有请求都需显式构造 *http.Request，再交由 http.Client 执行。默认客户端 http.DefaultClient 可直接用，但生产环境建议自定义带超时的实例。
-
http.Get(url)是快捷封装，但无法设 header、timeout 或复用连接，仅适合调试 - 发 JSON POST：先用
json.Marshal编码数据，再用bytes.NewReader包装为io.Reader传给http.NewRequest - 必须手动调用
resp.Body.Close()，否则连接不会释放，高并发下会耗尽文件描述符
client := &http.Client{Timeout: 10 * time.Second}
req, _ := http.NewRequest("POST", "https://api.example.com/v1/users", bytes.NewReader(payload))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Authorization", "Bearer abc123")
<p>resp, err := client.Do(req)
if err != nil { return }
defer resp.Body.Close() // 关键
为什么 http.DefaultClient 在长连接场景下容易出问题
http.DefaultClient 底层复用 http.DefaultTransport，而后者默认启用连接池（MaxIdleConns 和 MaxIdleConnsPerHost 均为 100），看似合理，但若服务端不支持 HTTP/2 或频繁重启，空闲连接可能被意外关闭，导致后续请求拿到失效连接并报 read: connection reset by peer。
- 线上服务应显式配置
Transport，尤其设置IdleConnTimeout（推荐 30s）和TLSHandshakeTimeout - 避免全局复用同一个
http.Client实例做不同目的的请求（如一部分要重试、一部分不能重试），应按语义拆分客户端 - 不要在请求中修改
req.URL.Scheme或req.Host后直接重用 ——http.Client会缓存 DNS 和连接，可能导致路由错乱
如何安全地解析 API 响应 JSON 并处理错误
HTTP 状态码 ≠ JSON 解析成功。常见错误是忽略 resp.StatusCode，直接 json.Decode(resp.Body)，结果 401/500 响应体里返回的是错误提示 JSON，结构却和正常响应不一致，导致 panic 或静默失败。
立即学习“go语言免费学习笔记（深入）”；
- 先检查
resp.StatusCode >= 200 && resp.StatusCode ，再读 body；非 2xx 建议统一用 <code>io.ReadAll拿原始字节，便于日志和分类处理 - 用
json.Unmarshal时，目标 struct 字段必须首字母大写（导出），且 tag 写对，比如json:"user_id"对应字段UserID int `json:"user_id"` - 别用
map[string]interface{}解析未知结构 —— 类型丢失、嵌套深了易写错 key 路径，优先定义明确 struct
API 服务端设计时，为什么 http.HandlerFunc 不够用
http.HandlerFunc 看似简单，但真实 API 需要路径参数提取、中间件（鉴权/日志/限流）、错误统一格式化、请求体自动绑定 —— 这些都要自己从 http.Request 里手工解析，重复代码多且易错。
- 路径参数：标准库不支持
/users/{id}这种写法，得靠正则或第三方路由器（如gorilla/mux、chi） - 中间件本质是函数套函数：
func(http.Handler) http.Handler，但组合顺序影响执行流，log - auth - handler和auth - log - handler行为不同 - 别在 handler 里写
fmt.Println打日志 —— 无法结构化、没上下文（如 traceID）、干扰测试，用log/slog或 zap 并注入到 handler 闭包中
真正麻烦的不是怎么发一个请求，而是怎么让一连串请求在超时、重试、重定向、连接复用、错误传播之间保持行为可预测 —— 这些细节藏在 http.Client 和 http.Transport 的几十个字段里，改错一个就可能让服务在流量高峰时雪崩。
