go 客户端在高并发 post 请求（如 ≥1000 路）时频繁报 `eof` 错误，主因是 http 连接复用机制与服务端非标准连接关闭行为冲突，导致客户端复用已失效的底层 tcp 连接。
该问题本质并非文件描述符耗尽或系统级连接数限制（尽管需排查），而是 Go net/http 客户端默认启用连接复用（keep-alive），而服务端在未发送 Connection: close 响应头的情况下主动关闭了连接——此时客户端缓存的连接池中对应连接已处于半关闭状态，后续请求复用该连接时即触发 EOF 错误。
关键修复点如下：
✅ 方案一：禁用连接复用（快速验证）
在每次请求中显式关闭连接，避免复用失效连接：
request, _ := http.NewRequest("POST", url2, postBytesReader)
request.Close = true // 强制本次请求不复用连接✅ 方案二：配置 Transport（推荐生产环境）
自定义 http.Transport，合理控制连接池行为，兼顾性能与健壮性：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
// 关键：启用对服务端静默断连的探测
TLSHandshakeTimeout: 10 * time.Second,
// 可选：启用 KeepAlive 探活（需服务端支持）
// KeepAlive: 30 * time.Second,
},
}✅ 方案三：添加重试与错误分类处理
EOF 常伴随网络抖动或服务端瞬时异常，建议封装带指数退避的重试逻辑：
func DoCreateWithRetry(js string, cli *http.Client) {
var err error
for i := 0; i < 3; i++ {
resp, err := cli.Do(request)
if err == nil {
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
fmt.Println(string(body))
return
}
if errors.Is(err, io.EOF) || strings.Contains(err.Error(), "EOF") {
time.Sleep(time.Millisecond * time.Duration(100<⚠️ 注意事项：
立即学习“go语言免费学习笔记（深入）”；
- defer resp.Body.Close() 必须在 err == nil 分支内执行，否则 resp 为 nil 会 panic；
- 原代码中 ioutil.ReadAll 已弃用，请改用 io.ReadAll（Go 1.16+）；
- 高并发下务必限制 goroutine 数量（如使用 semaphore 或 worker pool），避免资源耗尽；
- 服务端应检查是否设置了过短的 keepalive timeout、连接数限制（如 Nginx 的 limit_conn）或反向代理超时策略。
综上，EOF 是典型的客户端与服务端连接生命周期管理不一致所致。通过合理配置 Transport、显式控制连接生命周期并辅以错误重试，可彻底规避该问题，无需降级至单连接模式。
