在 Go 语言里使用标准库 net/http 发送请求，很多服务在单次调用时一切正常，一旦进入循环连续发送，就会随机出现 EOF 错误。这个现象通常和 HTTP 客户端的连接复用机制有关，而不是单纯的远端服务异常。下面从原理、排查与具体解决代码几个层面详细说明。
一、EOF 错误的底层原理
Go 的 http.Client 默认使用 http.DefaultTransport，其中开启了 HTTP/1.1 的 keep-alive。这意味着第一次请求完成后，底层的 TCP 连接并不会立刻关闭，而是被放入客户端连接池中，等待下一次发往同一个 host 的请求复用。这样的设计能降低握手开销，提升吞吐。
但是，如果服务端因为自身 idle timeout 或者代理层（如 Nginx）主动断开了这条空闲连接，而客户端连接池还认为它可用，下一次拿它发请求时，写数据可能成功，但读响应时就会从已经关闭的 socket 上读到 io.EOF。此时 Go 返回的 error 常常就是简单的 EOF，没有超时信息，容易让人误判为网络故障。
1.1 连接池的关键参数
Transport 中与复用相关的字段包括 MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout。当 IdleConnTimeout 设置过长，而服务端关闭得更快，就容易出现上述复用死连接的问题。理解这些参数是排查的基础。
另外，如果请求中显式写了 Connection: close 头，或者服务端响应里带了该头，连接不会被复用，EOF 反而不会出现，但性能会下降。因此问题多出现在“想复用却复用到了坏连接”的场景。
二、如何排查确认是连接复用导致的 EOF
遇到错误时不要只打印顶层 err，应当用 errors.Is 或类型断言看底层。若是 io.EOF，且发生在 client.Do 返回时，大概率是连接被服务端关了。可以临时把 Client 的 Transport 换成禁止复用的版本，观察错误是否消失。
下面是一段最小复现代码，连续发两次请求到同一个地址，并输出错误类型：
package main
import (
"errors"
"fmt"
"io"
"net/http"
"time"
)
func main() {
client := &http.Client{
Timeout: 5 * time.Second,
}
for i := 0; i < 3; i++ {
resp, err := client.Get("http://127.0.0.1:8080/ping")
if err != nil {
if errors.Is(err, io.EOF) {
fmt.Println("第", i, "次请求遇到 io.EOF，可能是连接复用问题")
} else {
fmt.Println("其他错误:", err)
}
continue
}
resp.Body.Close()
}
}
运行后如果仅第二次或之后出现 EOF，第一次正常，那么基本可以锁定是空闲连接被断开后的复用故障。此时再对比关闭 keep-alive 的表现，就能验证猜测。
2.1 使用自定义 Transport 观察
我们可以在 Transport 上设置 DisableKeepAlives 为 true，这样每次请求都新建连接，若 EOF 不再出现，就说明原配置下的复用逻辑是根因。该字段直接控制是否使用持久连接。
不过生产环境不能简单粗暴关掉复用，否则 QPS 稍高就会大量 TIME_WAIT。正确做法是在复用和容错之间找平衡，例如缩短空闲超时、增加重试。
三、可行的解决方案
针对连续发送时的 EOF，有多种处理思路，下面列出常用三种并给出代码。
3.1 方案 A：缩短空闲连接超时
让客户端连接池比服务端先放弃空闲连接，从源头避免拿到已被服务端关闭的连接。设置 IdleConnTimeout 小于服务端 idle timeout 即可。
package main
import (
"net/http"
"time"
)
func newClient() *http.Client {
return &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 10,
IdleConnTimeout: 30 * time.Second, // 小于服务端通常的 60s
},
Timeout: 5 * time.Second,
}
}
该方式改动小，性能影响低，适合大多数内部服务调用。需要注意的是不同域名空闲池独立，PerHost 参数要按实际并发调。
如果服务端超时不可控，还可以进一步把 MaxIdleConnsPerHost 调小，让空闲连接更快被淘汰，代价是新建连接略多。
3.2 方案 B：出错后重试并新建连接
由于 net/http 在遇到 EOF 时会自动丢弃该坏连接，下一次请求会建新连接，因此简单重试一次往往就能成功。封装一个带重试的 Do 方法：
package main
import (
"errors"
"io"
"net/http"
)
func doWithRetry(client *http.Client, req *http.Request, max int) (*http.Response, error) {
var resp *http.Response
var err error
for i := 0; i < max; i++ {
resp, err = client.Do(req)
if err != nil {
if errors.Is(err, io.EOF) {
continue // 重试，Transport 会换连接
}
return nil, err
}
return resp, nil
}
return resp, err
}
这种方式对调用方透明，不需要改服务端，也不会牺牲复用带来的性能。建议最大重试设为 2 到 3 次，避免雪崩。
要注意的是，重试仅对幂等请求（GET、PUT 等）安全，发 POST 且非幂等时需业务层确认。
3.3 方案 C：彻底关闭 keep-alive
在低频或调试阶段，可以直接 DisableKeepAlives。代码极其简单：
package main
import (
"net/http"
)
func disableKeepAliveClient() *http.Client {
return &http.Client{
Transport: &http.Transport{
DisableKeepAlives: true,
},
}
}
该方案能100%规避 EOF，但每次请求三次握手，高并发下客户端和服务端压力都大，仅建议测试或特殊场景使用。
综合来看，生产环境推荐方案 A 配合 B，既保留连接复用，又能自动从偶发坏连接恢复。
四、小结与最佳实践
Go 连续发 HTTP 请求遇到 EOF，核心在于默认 Transport 的 keep-alive 与服务端关闭策略不一致。排查时认准 io.EOF 并做对照实验；解决时优先调整 IdleConnTimeout 与重试，而不是一律禁复用。
建议在项目里统一封装一个配置了合理 Transport 和重试逻辑的 http.Client，避免各个模块随手用 http.Get 导致参数混乱。这样既能享受连接池性能，也能在连续请求时稳稳避开 EOF 陷阱。
GolangHTTP_clientEOF_error修改时间：2026-08-02 11:42:39