Golang如何实现HTTP长连接_Golang HTTP Keep-Alive实现
Go的http.Transport默认启用Keep-Alive，但需服务端配合；常见断连源于服务端关闭、请求体未读完或超时设置不当；调优关键参数包括MaxIdleConnsPerHost、IdleConnTimeout和ResponseHeaderTimeout。
Go 的 http.Transport 默认就启用 Keep-Alive
不需要额外配置，Go 标准库的 http.DefaultClient 和默认 http.Transport 已开启连接复用。只要服务端也支持（返回 Connection: keep-alive 且未显式关闭），底层 TCP 连接就会被缓存并复用。
关键点在于：Keep-Alive 是双向行为，客户端和服务端必须都配合。常见误判是看到请求头没带 Connection: keep-alive 就认为没启用——其实 Go 1.12+ 默认不显式发送该 header，但依然会复用连接。
-
http.Transport.MaxIdleConns：控制所有 host 共享的最大空闲连接数，默认为100 -
http.Transport.MaxIdleConnsPerHost：单个 host 最大空闲连接数，默认为100 -
http.Transport.IdleConnTimeout：空闲连接保活时间，默认30s（超过则关闭） -
http.Transport.TLSHandshakeTimeout和http.Transport.ResponseHeaderTimeout也会影响长连接稳定性
为什么你的长连接“没生效”？常见断连原因
现象往往是：连续发多个请求，Wireshark 显示每次都是新 TCP 握手，或 netstat 看不到复用的 ESTABLISHED 连接。大概率不是 Go 没开 Keep-Alive，而是以下任一情况触发了连接提前关闭：
- 服务端返回了
Connection: closeheader（比如 Nginx 默认在 HTTP/1.0 下这么做，或设置了keepalive_timeout 0） - 服务端主动关闭了空闲连接（如 Apache 的
KeepAliveTimeout设得太短） - 客户端请求中手动设置了
Connection: close（例如用req.Header.Set("Connection", "close")） - 请求体未读完（
resp.Body没Close()或没io.Copy(ioutil.Discard, resp.Body)），导致连接无法归还到 idle pool - HTTP/2 被协商启用后，Keep-Alive 概念弱化（连接天然复用），但某些代理会降级到 HTTP/1.1 并破坏复用逻辑
如何验证连接是否真的复用了？
不要只看 header，直接观察底层连接行为更可靠：
- 用
curl -v发两次请求，看第二条是否出现* Connection #0 to host xxx left intact - 在 Go 客户端加日志：设置
http.Transport.DialContext包裹原net.DialContext，打印每次新建连接的地址和时间戳 - 抓包过滤
tcp.flags.syn == 1，连续请求间无 SYN 包即复用成功 - 检查
http.Transport.IdleConnTimeout是否远小于服务端的 keepalive timeout（比如服务端设了 60s，客户端却用默认 30s，连接总在复用前被回收）
一个小技巧：临时把 IdleConnTimeout
5 * time.Minute，再压测对比连接数变化，能快速定位是不是超时导致的“假断连”。
高并发下需要调优的几个关键参数
默认值适合一般场景，但面对每秒数百请求、大量后端服务调用时，容易因连接池不足导致新建连接飙升，甚至 dial tcp: too many open files 错误：
- 增大
MaxIdleConnsPerHost（如设为200或更高），尤其当目标 host 多、QPS 高时 - 适当延长
IdleConnTimeout（如90s），避免频繁重建；但别设过长（> 120s），否则可能卡在服务端已关闭的连接上 - 务必设置
ResponseHeaderTimeout（如10s），防止某个后端 hang 住整个连接池 - 如果使用自定义
http.Client，记得复用它——每次 newhttp.Client都会创建独立的Transport实例，连接池不共享
最常被忽略的一点：http.Transport 是有状态的，一旦开始使用就不该再修改其字段（如运行时改 MaxIdleConns 不生效）。初始化后就固定配置，后续靠压测调整。
