在 Go 中使用 json.Decoder 解析 HTTPS 响应时，若未完整读取响应体，会导致连接无法复用、端口快速耗尽；需确保 decoder.Decode() 后显式消费剩余字节（如调用 io.Copy(ioutil.Discard, resp.Body)），或借助 decoder.More() 判断是否需清理。
在 go 中使用 `json.decoder` 解析 https 响应时，若未完整读取响应体，会导致连接无法复用、端口快速耗尽；需确保 `decoder.decode()` 后显式消费剩余字节（如调用 `io.copy(ioutil.discard, resp.body)`），或借助 `decoder.more()` 判断是否需清理。
Go 的 net/http 客户端默认支持 HTTP/1.1 keep-alive 和连接复用，但前提是必须完全读取响应体（resp.Body）后再关闭。否则，底层 http.Transport 会认为连接处于不确定状态，拒绝将其放回连接池，进而导致新建连接不断累积、本地端口被迅速占满（表现为 dial tcp: lookup failed: no such host 或 too many open files 等错误）。
当你使用 json.NewDecoder(resp.Body).Decode(&v) 时，解码器仅按需读取解析所需字节——例如，一个 JSON 对象 { "id": 123 } 可能只读取到 } 就结束，而响应体后续可能还包含换行、空格、甚至意外的多余数据（如服务端拼接了多个对象、或响应末尾有注释/分隔符）。此时 resp.Body 未被读尽，直接 defer resp.Body.Close() 会中断连接复用。
✅ 正确做法是：在 Decode() 成功后，主动清空剩余响应体。推荐方案如下：
import (
"encoding/json"
"io"
"io/ioutil" // Go 1.16+ 推荐替换为 io, io/fs
"net/http"
)
// 示例：安全解码单个 JSON 对象并确保连接复用
func fetchAndDecode(url string, data interface{}) error {
req, err := http.NewRequest("GET", url, nil)
if err != nil {
return err
}
// 不需要手动设置 "Connection: keep-alive" — Go client 默认启用
resp, err := client.Do(req)
if err != nil {
return err
}
defer resp.Body.Close() // 注意：此处 defer 是安全的，因后续操作不依赖 Body
decoder := json.NewDecoder(resp.Body)
if err := decoder.Decode(data); err != nil {
return err
}
// ✅ 关键：检查是否还有未读数据，若有则丢弃
if decoder.More() {
_, err := io.Copy(io.Discard, resp.Body)
if err != nil {
return err // 如网络中断，应视为错误处理
}
}
return nil
}⚠️ 注意事项：
- 不要依赖 ioutil.ReadAll(resp.Body) 全量读取：对大响应会占用过多内存，且与 json.Decoder 的流式解析初衷相悖；
- decoder.More() 仅适用于单对象解码场景：它检测解码器内部缓冲区是否还有未解析的 JSON 值（如数组项、对象后多余字符），但不保证 HTTP 响应体已全部到达——因此仍需 io.Copy(io.Discard, ...) 清理剩余字节；
- client 应复用（全局或长生命周期）：确保 http.Client 及其底层 http.Transport 是共享的，并配置合理的 MaxIdleConns 和 MaxIdleConnsPerHost（默认 100，生产环境建议显式设置）；
- Go 1.16+ 替代 ioutil.Discard：使用 io.Discard（无需额外 import）；ioutil 已弃用。
总结：连接复用不是“自动发生”的魔法，而是建立在严格遵守 HTTP 协议语义基础上的行为。只要确保每次请求后 resp.Body 被彻底读取（无论是否出错），Go 的连接池就能高效复用 TCP 连接，显著降低资源消耗与延迟。
