本文详解 go 程序批量请求 hacker news api 时出现 `eof json` 错误的根本原因——服务端异常关闭 http 连接但未发送 `connection: close` 头，导致客户端复用已断开的连接；并提供两种可靠修复方案：手动设置 `req.close = true` 或禁用 http 连接复用。
在 Go 中批量请求多个 URL（如 Hacker News 的 /item/{id}.json 接口）时，若直接使用 http.Get() 循环调用，常会遇到类似 invalid character 'E' looking for beginning of value 或 unexpected end of JSON input（底层常伴随 EOF）的错误。这并非 JSON 数据本身损坏，而是 HTTP 连接管理问题：目标服务器（如 hacker-news.firebaseio.com）在返回响应后静默关闭 TCP 连接，却未按 HTTP/1.1 规范发送 Connection: close 响应头。Go 的默认 http.Client 依赖该头部判断是否复用连接；当它误以为连接仍可用而尝试复用时，下一次读取将立即遭遇 EOF，导致 ioutil.ReadAll 或 json.Unmarshal 失败。
✅ 正确解决方案
方案一：为每个请求显式关闭连接（推荐，粒度细、影响小）
修改 get() 函数，不使用 http.Get()，而是构造 http.Request 并设置 req.Close = true：
func get(url string) ([]byte, error) {
req, err := http.NewRequest("GET", url, nil)
if err != nil {
return nil, err
}
req.Close = true // 强制本次请求后关闭连接
client := &http.Client{}
res, err := client.Do(req)
if err != nil {
return nil, err
}
defer res.Body.Close() // 注意：务必 defer 关闭 Body！
return io.ReadAll(res.Body) // 替换 ioutil.ReadAll（已弃用）
}⚠️ 注意：res.Body.Close() 必须被调用（此处用 defer），否则可能泄漏文件描述符；同时 io.ReadAll（Go 1.16+）替代已废弃的 ioutil.ReadAll。
方案二：全局禁用连接复用（适合调试或短生命周期程序）
在 main() 开始处配置自定义 http.Transport：
client := &http.Client{
Transport: &http.Transport{
DisableKeepAlives: true, // 所有请求均不复用连接
},
}
// 后续所有请求均通过此 client 发起
body, err := client.Get("https://...")该方式更彻底，但会增加 TCP 握手开销，不适用于高并发长期运行服务。
? 补充建议与最佳实践
-
添加超时控制：生产环境务必为 http.Client 设置 Timeout，防止单个失败请求阻塞整个流程：
client := &http.Client{ Timeout: 10 * time.Second, Transport: &http.Transport{DisableKeepAlives: true}, } - 错误处理需健壮：原代码中 fmt.Println(err) 后继续执行，可能导致 contents 包含不完整或损坏数据。建议记录错误并跳过，或使用 continue。
-
考虑并发优化（进阶）：当前为串行请求，效率低。可结合 sync.WaitGroup + goroutine 实现并发（注意控制并发数，避免触发服务端限流）：
var mu sync.Mutex var contents [][]byte sem := make(chan struct{}, 5) // 限制最多 5 个并发 for _, id := range ids[0:10] { sem <- struct{}{} go func(id int) { defer func() { <-sem }() body, err := get(fmt.Sprintf("https://.../item/%d.json", id)) if err == nil { mu.Lock() contents = append(contents, body) mu.Unlock() } }(id) } // 等待全部完成...
综上，EOF json 错误本质是客户端与服务端 HTTP 连接行为不一致所致。通过显式关闭请求连接或禁用 Keep-Alive，即可稳定获取 JSON 数据。优先采用方案一，兼顾可靠性与可控性。
