如何在Golang中处理网络请求_Golang net/http包请求示例_技术教程

最基础的 GET 请求需调用 http.Get，defer resp.Body.Close() 防泄漏，用 io.ReadAll 读响应体，检查 StatusCode；POST JSON 要设 Content-Type、json.Marshal 后 bytes.NewReader；必须自定义 Client 设 Timeout；复用 Client 并配置 Transport 连接池。

怎么用 `net/http` 发 GET 请求并读取响应

最基础的场景：发一个 GET，拿到响应体内容。关键不是“能不能发”，而是别漏掉 resp.Body.Close() —— 不关会导致连接泄漏，压测时很快耗尽文件描述符。

常见错误现象：too many open files、请求变慢、后续请求超时。

必须用 defer resp.Body.Close()（注意是 resp.Body，不是 resp）
用 io.ReadAll(resp.Body) 读全部内容，别直接用 resp.Body.Read() 手动循环（容易读不全或阻塞）
检查 resp.StatusCode，HTTP 状态码 200 不代表业务成功，但 4xx/5xx 通常该提前返回

resp, err := http.Get("https://httpbin.org/get")
if err != nil {
    log.Fatal(err)
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
if err != nil {
log.Fatal(err)
}
fmt.Println(string(body))

POST JSON 数据时怎么设置 header 和 body

发 JSON 是高频操作，但新手常卡在两处：没设 Content-Type，或把结构体直接传给 http.Post() —— 它只接受 []byte 或 io.Reader，不接受 struct。

使用场景：调第三方 API（如登录、提交表单），必须确保服务端能正确解析 JSON。

Content-Type: application/json 必须显式设置，否则服务端可能当 text/plain 处理
用 json.Marshal() 把 struct 转成 []byte，再用 bytes.NewReader() 包一层才能传给 http.NewRequest()
别用 http.Post()，它没法设 header；改用 http.NewRequest() + http.DefaultClient.Do()

data := map[string]string{"name": "alice", "age": "30"}
jsonBytes, _ := json.Marshal(data)
req, _ := http.NewRequest("POST", "https://www./link/dc076eb055ef5f8a60a41b6195e9f329", bytes.NewReader(jsonBytes))
req.Header.Set("Content-Type", "application/json")
resp, _ := http.DefaultClient.Do(req)
defer resp.Body.Close()

怎么加超时避免请求卡死

默认 HTTP client 没有超时，DNS 解析卡住、服务端不回包、网络抖动都会让 goroutine 永久挂起 —— 这是线上事故高发点。

性能影响：一个卡住的请求会拖垮整个 goroutine，如果并发量大，可能引发雪崩。

永远不要用 http.DefaultClient 做生产请求；自定义 http.Clien t 并设 Timeout
Timeout 是总超时（从发起到收到响应体结束），不是连接超时或读超时分开控制
如果需要更细粒度（比如连接 2s、读 5s），得用 Transport 配 DialContext 和 ResponseHeaderTimeout

client := &http.Client{
    Timeout: 10 * time.Second,
}
resp, err := client.Get("https://httpbin.org/delay/15") // 超过 10s 就报错

怎么复用连接避免频繁建连

短连接每请求都 TCP 握手 + TLS 协商，延迟高、CPU 消耗大。HTTP/1.1 默认支持 keep-alive，但得确保 client 和 server 都没禁用。

容易踩的坑：自己 new 出来没配 Transport 的 client，或者用了 http.DefaultClient 却没确认底层 Transport 是否被其他库污染。

复用 http.Client 实例（全局或单例），不要每次请求都 new
检查 Transport.MaxIdleConns 和 MaxIdleConnsPerHost，默认值太小（100/2），高并发时连接池不够用
确保服务端返回 Connection: keep-alive（现代服务基本都支持，但某些 Nginx 配置或老旧网关会强制 close）

client := &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        200,
        MaxIdleConnsPerHost: 200,
        IdleConnTimeout:     30 * time.Second,
    },
}

HTTP client 的行为细节藏在 http.Transport 和 http.Client 的字段里，而不是函数签名上。很多问题不是代码写错了，而是没意识到默认配置在生产环境根本不可用。