Go io.ReadAll 为什么会突然吃满内存：读取边界与分块处理

接口返回体从几百 KB 涨到几十 MB 后，最先出问题的通常不是业务逻辑，而是那行看起来无害的 data, err := io.ReadAll(resp.Body)。它会持续读取直到 EOF，并把内容集中放进一个 []byte；如果后面还要转成字符串或 JSON 对象，峰值内存会继续叠加。

输入确定很小、且调用方确实需要完整内容时，io.ReadAll 很合适；输入可能变大或边界不可信时，先限制读取范围，或者直接按块调用 Read，不要把“读取成功”误当成“内存可控”。

故障现场：一行 io.ReadAll 为什么能把进程顶到 OOM

假设服务接收一个上游响应，平时只有 2 MB，异常时却可能返回 200 MB。下面的写法会一直读到 EOF：

data, err := io.ReadAll(resp.Body)
if err != nil {
    return err
}
return handle(data)

这里的 data 必须容纳完整输入。读取过程中，内部字节切片可能经历多次扩容：旧数组还没有立刻消失，新数组已经分配，复制也需要短暂的 CPU 和内存。若 handle 再把它转换为字符串，或者解码成结构体，原始字节和解析结果还可能同时存活。

因此，监控里看到的峰值不一定等于响应体大小。真正要追的是从 Read 到 []byte，再到后续处理对象的整条数据路径。

先用 len 和 cap 把增长过程看清楚

io.ReadAll 的实现细节会随 Go 版本变化，业务代码不应该依赖某个固定扩容倍数。但切片的两个量很稳定：len 是已有数据长度，cap 是当前底层数组能容纳的上限。只要追加后的长度超过 cap，就可能分配新数组并复制旧内容。

这也是为什么只在函数结束后打印 len(data) 不够。若要定位峰值，应结合 pprof 或压测观察读取期间的分配，并检查 handle(data) 是否产生第二份大对象。

第一道修复：用 io.LimitReader 给输入设硬边界

如果业务只接受最多 8 MiB 的内容，可以把边界写进读取器，而不是依赖调用方自觉：

const maxBody = 8  maxBody {
    return fmt.Errorf("body exceeds %d bytes", maxBody)
}
return handle(data)

多读 1 个字节是为了区分“刚好达到上限”和“超过上限”。命中边界时尽快停止后续解析，并记录明确的业务错误；不要把截断的数据继续交给 JSON、压缩包或自定义协议解析器。

这里的 io.LimitReader 解决的是输入上限，不是流式处理。只要最后仍调用 io.ReadAll，上限以内的内容依旧会完整驻留在 []byte 中。

第二道修复：Read 配合固定缓冲区处理大输入

如果业务可以逐块处理，就不要先构造完整 []byte。下面的函数让内存主要由固定的 buf 决定：

func consume(r io.Reader, handle func([]byte) error) error {
    buf := make([]byte, 32*1024)
    for {
        n, err := r.Read(buf)
        if n > 0 {
            if err := handle(buf[:n]); err != nil {
                return err
            }
        }
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return err
        }
    }
}

控制流只有三件事：Read 返回数据就交给 处理块，返回 EOF 就正常结束，其他错误立即退出。handle 必须在本次调用内消费或复制 buf[:n]；如果把这个切片保存到下一轮，下一次 Read 会覆盖它的内容。

对于需要按行、按记录或按协议帧处理的场景，可以在 handle 内维护少量跨块状态。这样保留的是未完成记录，而不是整个输入。

复查结果：什么时候保留 io.ReadAll，什么时候拆成分块路径

我更建议把选择写成可验收的规则：小而有明确上限的配置响应可以保留 io.ReadAll；外部上传、代理转发和未知长度响应先经过 io.LimitReader；日志归档、文件复制和大响应处理则直接使用固定缓冲区。

压测时同时观察输入大小、进程 RSS、堆分配和失败响应。若限制命中后仍有大幅增长，再检查 handle 是否复制了块数据，或是否把多个块缓存成了另一个集合。不要只把 io.ReadAll 换成一段复杂代码，却没有确认业务真的能逐块消费。

常见问题

io.ReadAll 会不会主动限制读取大小？

不会。它会持续读取直到 EOF。需要上限时，在它前面包一层 io.LimitReader，并对超过上限的结果单独处理。

把 io.ReadAll 换成 io.ReadAll(io.LimitReader(...)) 就是流式读取吗？

不是。这样只是限制了完整收集的最大尺寸；结果仍然是一个完整的 []byte。真正的分块路径要在每次 Read 后立即处理 buf[:n]。

Read 返回 n 大于 0 时同时返回 EOF，应该丢掉这批数据吗？

不应该。先处理 n > 0 的有效数据，再判断 EOF；代码不能只看错误值而忽略本次已经读到的字节。

为什么最终 len 没有很大，内存峰值却很高？

扩容复制、字符串转换、JSON 解码或业务缓存都可能与原始切片短暂共存。应在读取过程和后续处理阶段分别采样，而不是只看最终返回值。

小结

io.ReadAll 的风险边界很明确：它把输入完整收集起来，内存预算随输入大小变化。先用 io.LimitReader 拦住不可信上限；当业务允许增量处理时，改用固定 buf 调用 Read，并让 处理块 及时消费数据。这样既保留了 EOF 和错误处理的清晰控制流，也避免把整份输入长期留在内存里。