Go 的 http.Server 默认支持 HTTP Keep-Alive，但需显式设置 IdleTimeout 并确保客户端、反向代理协同；关键超时参数为 IdleTimeout（空闲连接）、ReadTimeout 和 WriteTimeout（单请求）；验证方式包括日志观察 RemoteAddr 复用或 ss 查看 ESTABLISHED 连接数。
Go 的 http.Server 默认就支持 HTTP Keep-Alive
只要不显式关闭连接，Go 标准库的 http.Server 会自动复用 TCP 连接处理后续请求。它在响应头中默认添加 Connection: keep-alive（HTTP/1.1 下），且不会主动发 Connection: close。你不需要额外写代码启用——但必须确保客户端也配合，否则连接仍会断开。
常见干扰点：
- 客户端（如 curl、Postman 或某些 SDK）未设置
Connection: keep-alive请求头，或显式设为close - 反向代理（如 Nginx）默认未开启长连接，或配置了
proxy_http_version 1.1但漏配proxy_set_header Connection '' - 服务端设置了
http.Server.ReadTimeout/WriteTimeout过短，导致连接被提前关闭
http.Server 的超时字段直接影响 Keep-Alive 行为
Keep-Alive 不是“永远不断”，而是由多个超时参数共同控制空闲连接的生命周期。最关键的三个字段是：
-
IdleTimeout：空闲连接最长保持时间（推荐显式设置，如5 * time.Minute）。这是决定连接是否被 server 主动关闭的核心参数 -
ReadTimeout：从读取请求开始到读完全部 header + body 的最大耗时（影响大 body 或慢客户端） -
WriteTimeout：从收到完整请求到写完响应的总耗时（含 handler 执行时间）
注意：ReadTimeout 和 WriteTimeout 是 per-request 的，而 IdleTimeout 是 per-connection 的。如果只设了前两者，IdleTimeout 默认为 0（即不限制空闲时间），但实际仍受底层 TCP keepalive 和操作系统限制。
如何验证 Keep-Alive 是否生效
最直接的方式是抓包或看连接复用日志。在服务端加一行日志即可快速确认：
log.Println("Conn local addr:", conn.LocalAddr(), "remote addr:", conn.RemoteAddr())然后用同一客户端连续发两个请求（如 curl -H "Connection: keep-alive" http://localhost:8080），观察日志中 RemoteAddr() 是否相同、LocalAddr() 是否一致——相同说明复用了连接。
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
更可靠的方法是用 netstat 或 ss 查看 ESTABLISHED 连接数变化：
ss -tn state established '( dport = :8080 )' | wc -l
发起 10 次请求后，若连接数仍为 1（而非 10），基本可判定 Keep-Alive 生效。
客户端也要正确使用长连接
Go 客户端默认也开启 Keep-Alive，但要注意：
-
http.DefaultClient的Transport中MaxIdleConns和MaxIdleConnsPerHost默认都是 100，够用；但如果并发极高，需调大 - 务必复用同一个
*http.Client实例，不要每次请求都 new 一个——否则连接池失效，每个请求都新建 TCP 连接 - 手动构造
http.Request时，别误删Connection头；用req.Header.Set("Connection", "keep-alive")是冗余的（HTTP/1.1 默认就是）
一个典型错误是：在循环里 new http.Client 并调用 Do()，这会导致大量 TIME_WAIT 和连接无法复用。
Keep-Alive 看似简单，但真正稳定运行依赖服务端超时配置、反向代理透传、客户端连接池三者协同。最容易被忽略的是 IdleTimeout 的缺失和反向代理对 Connection 头的篡改。
