Go io.ReadAll 为什么会因为响应体长度失控而 OOM

我遇到过一种很容易误判的 Go OOM：接口平时只返回几 KB，代码里的 io.ReadAll(resp.Body) 也没有循环，看起来不可能“慢慢吃掉”很多内存；但当上游返回错误页、异常代理响应，或者响应体没有可靠长度时，进程的堆却会持续上涨，最后被操作系统杀掉。

根因通常不是 io.ReadAll 有一个隐藏的固定上限，而是它的语义就是一直读到 EOF。只要响应体的边界失控，应该先判断状态码，再用 io.LimitReader 或流式处理建立应用层上限。

官方参考：https://pkg.go.dev/io、https://pkg.go.dev/net/http

问题现场：为什么小接口也能把内存顶满

这段代码最直观，也最容易被直接复制到业务里：

resp, err := client.Do(req)
if err != nil {
	return err
}
defer resp.Body.Close()

// ReadAll 会持续读取，直到 Body 返回 EOF。
body, err := io.ReadAll(resp.Body)
if err != nil {
	return err
}
return handle(body)

只要服务端最终返回 EOF，它就能正常结束；问题在于“最终返回 EOF”并不等于“响应一定很小”。Content-Length 缺失、值为未知，或响应采用分块传输时，客户端仍然要从 Body 中持续读取。即使有长度，长度本身也只是对端提供的元数据，不是业务层愿意承受的内存预算。

如果上游把一个很大的错误页面、代理诊断内容或持续输出的流当作普通 JSON 处理，ReadAll 会把已经读取的字节放进一个不断增长的切片。扩容时还可能同时存在旧底层数组和新底层数组，峰值会比最终正文更高。

初步判断：先不要把 OOM 归咎于 JSON 解析

排查时我会先把链路拆成三段：网络读取、字节缓存、业务解析。若堆曲线在进入 json.Unmarshal 前已经明显上涨，最先要怀疑的是 io.ReadAll；如果读取后的字节只有几 MB，而解析阶段才出现峰值，才继续看目标结构体、字符串复制和嵌套对象。

下面几个现象很有区分度：

动手验证：Content-Length 不是安全边界

resp.ContentLength 适合帮助你了解响应，但不能单独作为内存保护。值为负数表示长度未知；分块响应没有一个可以提前信任的总长度。更重要的是，业务是否允许读取 1 MB、8 MB 还是 32 MB，是应用协议的决定，不应完全交给服务器响应头。

因此，“先判断长度再 ReadAll”只能覆盖一部分情况：

if resp.ContentLength > maxBodySize {
	// 这个判断只能拦截已知且超过上限的长度。
	return fmt.Errorf("response body too large: %d", resp.ContentLength)
}

// 未知长度的响应仍然可能在这里持续增长。
body, err := io.ReadAll(resp.Body)

如果长度未知，第二次读取仍然没有边界。真正的保护应该包在 Reader 上，而不是只依赖头部字段。

定位原因：失败响应为什么特别容易放大问题

很多客户端只在成功分支里考虑业务 JSON，却把错误响应也走同一条“读取全部正文”的路径。实际环境中，网关、反向代理和上游服务可能返回 HTML 错误页、诊断信息，甚至不断输出的错误流。状态码本身已经告诉我们这不是正常业务数据，此时通常只需要一个可记录的短摘要。

const maxErrorBody = 64 = 300 {
	// 错误响应只取有限摘要，避免把网关页面全部放进内存。
	limited := io.LimitReader(resp.Body, maxErrorBody+1)
	data, readErr := io.ReadAll(limited)
	if readErr != nil {
		return fmt.Errorf("read error response: %w", readErr)
	}
	if int64(len(data)) > maxErrorBody {
		data = data[:maxErrorBody]
	}
	return fmt.Errorf("upstream status %s: %s", resp.Status, strings.TrimSpace(string(data)))
}

这里多读取一个字节，是为了知道正文是否超过摘要上限；截断后再记录日志，可以避免错误信息本身把日志系统拖垮。defer resp.Body.Close() 仍然要保留，它负责结束响应体生命周期。

修复方案：给成功响应建立硬上限

成功响应也不能默认无限大。最小改动是用 io.LimitReader 包装 Body，并把上限设为“允许正文大小加一”。当多读到一个字节时，就能区分“正好达到上限”和“已经超限”。

const maxBodySize = 8  maxBodySize {
		return nil, fmt.Errorf("response body exceeds %d bytes", maxBodySize)
	}
	return body, nil
}

io.LimitReader 在达到给定字节数后返回 EOF，所以这里的 EOF 只是“限制 Reader 已经读够了”的信号，不代表原始响应体一定自然结束。也正因为如此，必须通过长度判断把超限变成明确错误，不能仅凭 ReadAll 返回 nil error 就认为响应合规。

验证结果：什么场景应该改成流式处理

上限适合“正文应该有一个可接受最大值”的接口。如果响应本来就是下载、日志流、事件流或大文件，就不要把它先变成完整的 []byte。应直接把 Body 复制到文件、对象存储或下游 Writer，并用 io.LimitReader 限制总量，或者设计增量解析器。

func copyToFile(resp *http.Response, dst io.Writer, maxBytes int64) error {
	defer resp.Body.Close()

	// 复制过程使用固定上限，避免下载接口退化成无界缓存。
	n, err := io.CopyN(dst, resp.Body, maxBytes+1)
	if err != nil && err != io.EOF {
		return fmt.Errorf("copy response: %w", err)
	}
	if n > maxBytes {
		return fmt.Errorf("response exceeds %d bytes", maxBytes)
	}
	return nil
}

这里的关键不在于把每个响应都限制成同一个数字，而是让每一种响应类型都有明确策略：

• 成功 JSON：使用有界读取，超限立即失败。
• 失败响应：只保留限长摘要，状态码和摘要一起进入错误。
• 文件或流：边读边写，避免完整正文驻留内存。
• 必须完整缓存的内容：把上限、超限行为和监控指标写进协议约定。

总结：排查 io.ReadAll OOM 的顺序

看到 Go 进程因为响应体 OOM 时，我会按这个顺序检查：

1. 确认内存上涨发生在读取阶段还是解析阶段。
2. 查看失败状态是否也进入了完整正文读取。
3. 不要把 Content-Length 当成应用层上限。
4. 用 io.LimitReader 多读一个字节，明确识别超限。
5. 对大文件和流式响应改用边读边写或增量解析。

一句话概括：io.ReadAll 不是“读取一小段 body”的意思，而是“读取到 EOF”。当 EOF 不代表业务可接受的大小时，内存边界必须由调用方主动建立。

常见问题

只检查 ContentLength 就够了吗？

不够。未知长度或分块响应仍然可能很大；即使长度已知，也应该用业务允许的最大值保护实际读取。

LimitReader 返回 EOF 是不是响应读完了？

不一定。它可能只是达到包装器的上限。多读一个字节并检查长度，才能把超限和自然结束区分开。

关闭 Body 后还需要读完吗？

不应为了连接复用而无界读完未知响应。先确保 Body 关闭；是否排空、排空多少，应根据响应大小和连接复用需求做受控处理。