go客户端连接未复用的根本原因不是keep-alive未开启，而是配置与使用不当：未调用resp.body.close()、maxidleconnsperhost默认值2过小、idleconntimeout设置不合理、服务端返回connection: close或nginx代理配置错误（如proxy_set_header connection ''），导致连接无法归还池或被提前关闭。
Keep-Alive 不是客户端“开启”的属性，而是 HTTP/1.1 的默认行为 —— Go 的 http.Client 和标准库服务端都默认支持它。真正决定连接是否复用的，是配置、生命周期管理与中间件协同，不是开关。
为什么你的 Go 客户端没复用连接？
常见现象：Wireshark 看到每个请求都新建 TCP 连接；netstat -an | grep :8080 大量 TIME_WAIT；curl -v 显示 Connection: close 响应头。
- 没调用
resp.Body.Close()—— 连接无法归还连接池，直接被丢弃 - 手动设置了
req.Header.Set("Connection", "close")—— 服务端收到后立刻跳过 Keep-Alive 流程 - 用了未配置的
http.DefaultClient，但目标服务并发高，MaxIdleConnsPerHost默认值 2 不够用，连接池快速耗尽 - 自定义了
http.Transport却漏设IdleConnTimeout，空闲连接 30 秒后被回收，但客户端间隔 >30 秒才发下个请求，复用失败
如何配对 http.Client 的 Transport 参数
复用连接依赖 http.Transport 的连接池，不是靠“启用 Keep-Alive”这个动作。
-
MaxIdleConns：全局最大空闲连接数，建议 ≥100（避免连接池满后排队） -
MaxIdleConnsPerHost：每个 host 最大空闲连接数，默认 2，高并发场景必须调高（如 10–50） -
IdleConnTimeout：空闲连接存活时间，应略大于客户端最大空闲间隔（如 60s），太短会频繁重建 -
TLSHandshakeTimeout和ExpectContinueTimeout也需设合理值，否则 handshake 卡住会阻塞整个连接池
示例：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 20,
IdleConnTimeout: 60 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
Timeout: 30 * time.Second,
}
服务端 http.Server 的 timeout 怎么配才不破坏复用？
ReadTimeout 和 WriteTimeout 是 per-request 的硬限制，它们不区分“传输中”和“空闲”，超时就杀连接 —— 这会直接干掉 Keep-Alive。
-
IdleTimeout才是控制空闲连接寿命的唯一正确参数（Go 1.8+），必须显式设置（默认 0 表示不限，但受其他 timeout 拖累） -
ReadTimeout应覆盖 header + body 读取全过程，设太长会卡 goroutine；建议 ≤5s -
WriteTimeout覆盖响应写入（含 flush），流式接口（SSE）需设为 0，靠IdleTimeout控制 - 三者需协调：
IdleTimeout≥ 客户端预期最大空闲间隔，且IdleTimeout>ReadTimeout和WriteTimeout
典型配置：
srv := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 60 * time.Second,
}
Nginx 或其他反向代理怎么配合？
哪怕客户端和服务端都配对了，中间件一动，Keep-Alive 就失效。
-
proxy_http_version 1.0：强制降级，HTTP/1.0 默认无 Keep-Alive -
proxy_set_header Connection ''：清空 Connection 头，服务端收不到keep-alive提示 -
proxy_buffering off+chunked_transfer_encoding off可能干扰流式响应复用 - Nginx 的
keepalive_timeout必须 ≥ 后端IdleTimeout，否则它先关连接
正确 Nginx 配置片段：
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
proxy_set_header Upgrade $http_upgrade;
keepalive_timeout 65;
}
真正卡住 Keep-Alive 的地方，往往不在代码里那几行 IdleTimeout 设置，而是在你没注意到的 resp.Body.Close() 缺失、Nginx 的 proxy_set_header Connection ''、或者 MaxIdleConnsPerHost 还卡在默认值 2。这些点不排查干净，调再久 timeout 也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
