是，go 1.20+ 环境必须，因 net/http 的 keepalive 行为在该版本后有关键修复：客户端默认启用 keepalive，服务端超时控制更稳定；旧版可能忽略 setkeepalive 或触发非预期关闭。
Go 1.20+ 环境是否必须？
是，net/http 的 KeepAlive 行为在 Go 1.20 后有关键修复：客户端默认启用 http.Transport 的 KeepAlive，且服务端对长连接的超时控制更稳定。低于该版本，SetKeepAlive 可能被忽略或触发非预期关闭。
实操建议：
- 用
go version确认 ≥go1.20；若旧版，升级到go1.21.x更稳妥（修复了某些 TLS + KeepAlive 组合下的连接复用失败） - Windows 用户注意：避免从官网下载 .msi 安装包后未重启终端——PATH 可能未生效，直接运行
go env GOPATH验证 - Linux/macOS 推荐用
go install golang.org/dl/go1.21@latest+go1.21 download管理多版本，比手动替换/usr/local/go安全
心跳用 TCP 还是 HTTP？
HTTP 更易落地，但本质仍是 TCP 层保活；真正决定“是否断连”的是底层 TCP 的 keepalive 参数，HTTP 只是应用层触发时机。
实操建议：
- 服务端无需额外写“心跳接口”，靠
http.Server的IdleTimeout和ReadTimeout控制连接生命周期即可 - 客户端必须显式配置
http.Transport：tr := &http.Transport{ IdleConnTimeout: 30 * time.Second, KeepAlive: 10 * time.Second, }其中KeepAlive是 TCP 层探测间隔，IdleConnTimeout是空闲连接最大存活时间，二者需配合——若后者太短，心跳还没发就被关了 - 别依赖
http.Client.Timeout控制长连接，它只管单次请求，不影响连接池行为
如何验证连接真没断？
打印日志或抓包看到 “reused connection” 不等于连接可靠；得看实际数据流是否持续、无重连。
实操建议：
- 服务端加一行日志：
log.Printf("conn %p reused: %v", conn, conn.RemoteAddr())放在http.ServeHTTP入口，观察同一地址是否复用相同指针 - 客户端用
curl -v http://localhost:8080/health观察响应头是否有Connection: keep-alive，并检查curl输出里是否出现* Connection #0 to host localhost left intact - 最硬核方式：用
ss -t -o state established '( sport == :8080 )'（Linux）或lsof -i :8080（macOS），看连接的timer字段是否为keepalive，且time值在递减
为什么本地测试总“秒断”？
常见于 macOS 或某些 Linux 发行版，默认 TCP keepalive 时间长达 2 小时，远超服务端 IdleTimeout，导致连接先被服务端关，客户端还傻等。
实操建议：
- 服务端设
IdleTimeout≤ 60 秒，客户端KeepAlive设为 15–30 秒，确保探测频率高于服务端超时阈值 - macOS 用户需调系统参数：
sudo sysctl -w net.inet.tcp.keepidle=15000（单位毫秒），否则即使 Go 设置了KeepAlive，内核也不会发探测包 - Docker 容器内运行时，宿主机 TCP 参数不透传，必须在容器启动时用
--sysctl net.ipv4.tcp_keepalive_time=15显式设置
真实环境里，NAT 网关、负载均衡器的空闲超时往往比代码设的还短，心跳机制真正起效前，得先确认中间设备允许长连接存活。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
