Go HTTP Server默认支持Keep-Alive，但需正确配置ReadTimeout、WriteTimeout和IdleTimeout三个参数，并确保客户端与中间件（如Nginx）配合，否则连接仍会被关闭。
Go HTTP Server 默认就支持 Keep-Alive，但容易被中间件或超时配置关掉
Go 的 http.Server 默认启用 HTTP/1.1 Keep-Alive，只要客户端也支持（现代浏览器、curl 等都默认支持），连接就会复用。但实际中常因配置不当导致连接被提前关闭。
常见错误现象：Connection: close 出现在响应头里；Wireshark 或 curl -v 显示每次请求都新建 TCP 连接；netstat -an | grep :8080 看到大量 TIME_WAIT 连接堆积。
-
ReadTimeout/WriteTimeout会强制关闭空闲连接 —— 它们不区分“正在传输”和“空闲等待”，只要超时就杀连接 -
IdleTimeout才是控制 Keep-Alive 空闲时长的正确参数（Go 1.8+），必须显式设置，否则用默认值 0（即不限制空闲时间，但受其他 timeout 影响） - 反向代理（如 Nginx）若配了
proxy_http_version 1.0或proxy_set_header Connection ''，会破坏 Keep-Alive
正确配置 http.Server 的三个关键 timeout 参数
Keep-Alive 的生命周期由三个 timeout 共同决定：读、写、空闲。只调一个，往往白配。
典型配置示例：
立即学习“go语言免费学习笔记（深入）”；
srv := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 5 * time.Second, // 防卡死：从 socket 读 header + body 的总上限
WriteTimeout: 10 * time.Second, // 防卡死：写响应的总上限（含 flush）
IdleTimeout: 30 * time.Second, // Keep-Alive 关键：连接空闲多久后关闭
}-
ReadTimeout和WriteTimeout是 per-request 的硬限制，不能设太长，否则阻塞 goroutine -
IdleTimeout应 ≥ 客户端预期的最大空闲间隔（比如浏览器通常 5–60 秒），但不宜远超，避免连接长期占着 fd - 如果服务要支持长轮询或流式响应（如 SSE），
WriteTimeout应设为 0（禁用），靠IdleTimeout控制连接寿命
客户端也要配合：HTTP/1.1 + Connection 头别乱删
服务端开了 Keep-Alive，客户端没发对请求，照样白搭。尤其在写 Go 客户端或对接第三方 SDK 时容易出错。
- Go 的
http.Client默认启用 Keep-Alive，但若手动设置了Transport却忘了配MaxIdleConns，连接池会退化成每请求新建连接 - 务必检查是否误加了
req.Header.Set("Connection", "close")—— 这会直接让服务端跳过 Keep-Alive 流程 - 使用
curl -H "Connection: keep-alive"测试时，注意 curl 默认已带该头；但某些旧脚本或嵌入式 HTTP 库可能默认发 HTTP/1.0 - Node.js、Python requests 等主流客户端默认 OK，但自研 C/C++ 或 Rust 客户端需确认是否显式写了
Connection: keep-alive
调试时别只看响应头，得抓包看 TCP 层行为
响应头里有 Connection: keep-alive 不代表连接真复用了。TCP 层是否复用，才是最终答案。
- 用
curl -v http://localhost:8080/api看响应头只是第一步；接着再跑一次，观察是否复用同一端口（curl -v日志里显示* Connected to localhost (127.0.0.1) port 8080 (#0)中的(#0)变成(#1)就说明新建连接） - 更准的方法是用
tcpdump -i lo port 8080或 Wireshark，过滤 SYN 包：连续请求间没有新 SYN，只有 ACK/PUSH，就是复用成功 - Linux 上可查连接状态：
ss -tn sport = :8080 | grep ESTAB，多次请求后如果 ESTAB 连接数没涨，基本稳了 - 注意：HTTP/2 默认多路复用，
Connection头不再出现，但复用效果更强 —— 如果你启用了 TLS 并支持 ALPN，优先走 HTTP/2 更省事
Keep-Alive 的边界很薄：服务端参数、客户端行为、中间网络设备（尤其是某些企业防火墙会强制 60 秒断连）全得对齐。少一个环节，连接就回退到短连接。
