Go 1.4 的 http.Server 默认不主动关闭空闲连接，但若未显式配置超时参数，底层 TCP 连接可能被中间设备或客户端误判为中断；正确设置 ReadTimeout 和 WriteTimeout 可有效管理空闲连接生命周期，避免 “use of closed network connection” 错误。
go 1.4 的 `http.server` 默认不主动关闭空闲连接，但若未显式配置超时参数，底层 tcp 连接可能被中间设备或客户端误判为中断；正确设置 `readtimeout` 和 `writetimeout` 可有效管理空闲连接生命周期，避免 “use of closed network connection” 错误。
在 Go 1.4 中，http.Server 尚未引入 IdleTimeout（该字段始于 Go 1.8），因此无法直接配置“仅针对空闲连接”的超时。但可通过组合 ReadTimeout 和 WriteTimeout 实现近似效果：这两个超时均以请求的完整生命周期为起点——即从连接建立或上一个请求读取开始计时，而非纯粹的空闲时间。虽然语义上不完全等同于现代版本的 IdleTimeout，但在 Go 1.4 环境下，这是最可靠、最直接的空闲连接保活/清理手段。
关键在于：若你的 API 响应耗时长达 10 秒，而默认 ReadTimeout 为 0（即无限制），看似安全；但实际中，若客户端在请求发送后短暂静默（如慢速上传、网络抖动），或服务端处理逻辑中存在阻塞等待，ReadTimeout 仍可能触发连接关闭，导致后续写入失败并抛出 read tcp ...: use of closed network connection。
✅ 正确做法是显式设置合理的超时值，确保覆盖最长预期处理时间，并留有一定余量：
server := &http.Server{
Addr: ":8080",
Handler: yourHandler,
ReadTimeout: 15 * time.Second, // 必须 ≥ 最长单次请求读取+处理时间（如 10s 响应 + 缓冲余量）
WriteTimeout: 15 * time.Second, // 同样需覆盖响应写入耗时，防止 Write 调用阻塞
}
log.Fatal(server.ListenAndServe())
⚠️ 注意事项：
- ReadTimeout 从连接建立或每次读取操作开始计时，涵盖请求头读取、请求体读取及整个处理过程；若处理逻辑含 time.Sleep(10 * time.Second)，该时间计入 ReadTimeout。
- WriteTimeout 从响应写入开始计时，确保 WriteHeader 和 Write 不因网络缓慢而无限挂起。
- MaxIdleConnsPerHost 是客户端侧配置，仅影响客户端复用连接的能力，无法阻止服务端主动断连；服务端是否关闭连接，完全取决于其自身的超时设置与底层 TCP keepalive 行为。
- Go 1.4 不支持 SetKeepAlivePeriod 或 IdleTimeout，切勿尝试访问不存在的字段，应专注合理设定 Read/WriteTimeout 并配合客户端重试逻辑。
总结：在 Go 1.4 环境下，解决空闲连接被意外关闭的核心是——主动、保守地设置 ReadTimeout 和 WriteTimeout，使其严格大于业务最大延迟（如 10 秒响应）并保留至少 3–5 秒安全余量。这不仅能规避连接中断错误，还能提升服务稳定性与可观测性。
