本文详解 go 中使用 `http.client` 进行高并发 post 请求时频繁返回 `eof` 错误（尤其在请求数 ≥1000 时）的根本原因——连接复用与服务端非预期断连的冲突，并提供可落地的修复方案，包括 transport 配置优化、请求级控制及资源管理最佳实践。
在 Go 的 net/http 包中，http.Client 默认启用连接复用（HTTP Keep-Alive），以提升性能。但当服务端（如 Nginx、负载均衡器或后端应用）因超时、连接数限制（例如 max_connections_per_client）、主动关闭空闲连接，却未正确发送 Connection: close 响应头时，Go 客户端会误认为该 TCP 连接仍可用。当下一个请求尝试复用该已关闭的连接时，底层 read() 系统调用立即返回 EOF，最终表现为 Post ...: EOF 错误——这正是你遇到问题的核心机制。
✅ 正确修复方式（推荐组合使用）
1. 配置 http.Transport：显式控制连接生命周期
client := &http.Client{
Transport: &http.Transport{
// 禁用 HTTP/2（某些旧服务端兼容性差）
ForceAttemptHTTP2: false,
// 设置空闲连接最大存活时间，避免复用过期连接
IdleConnTimeout: 30 * time.Second,
// 限制每个 host 的最大空闲连接数（防资源耗尽）
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
// 可选：设置连接获取超时，避免 goroutine 阻塞
ResponseHeaderTimeout: 10 * time.Second,
},
}2. 在请求级别强制关闭连接（临时兜底）
若无法修改服务端或 Transport，可在单次请求中明确告知不复用：
request, _ := http.NewRequest("POST", url2, postBytesReader)
request.Close = true // 关键：跳过连接池，每次新建连接⚠️ 注意：此方式牺牲性能，仅建议用于调试或低频关键请求。
3. 修复资源泄漏：defer 必须在函数内及时执行
你原代码中 defer resp.Body.Close() 写在 if err != nil 分支之后，导致错误时 Body 未关闭；且 defer 在 goroutine 中延迟执行，易引发文件描述符泄漏。应改为：
func DoCreate(js string, cli *http.Client) {
url2 := "http://xvz.myserver.com:9000/path/create"
postBytesReader := bytes.NewReader([]byte(js))
request, _ := http.NewRequest("POST", url2, postBytesReader)
resp, err := cli.Do(request)
if err != nil {
fmt.Printf("Request failed: %v\n", err)
return // 错误时直接返回，避免后续执行
}
defer resp.Body.Close() // ✅ 立即 defer，确保无论成功失败都关闭
body, err := io.ReadAll(resp.Body) // 注意：ioutil 已弃用，用 io.ReadAll
if err != nil {
fmt.Printf("Read response body failed: %v\n", err)
return
}
fmt.Println(string(body))
}? 排查建议
- 使用 curl -v 或 Wireshark 抓包，确认服务端是否在响应头中缺失 Connection: close 或返回了异常 RST；
- 检查服务端配置（如 Nginx 的 keepalive_timeout、max_conns）；
- 监控客户端进程的文件描述符使用量：lsof -p
| wc -l，若接近系统上限（如 1024），说明存在泄漏。
✅ 总结
EOF 并非 Go 客户端 Bug，而是客户端连接复用机制与服务端连接管理策略不一致的典型表现。根本解法是合理配置 http.Transport，而非简单增加 request.Close = true。结合连接超时、空闲连接数限制与及时关闭 Body，即可稳定支撑数千级并发 POST 请求。
