Go io 怎样限制 ReadAll 的最大内存

如果输入来自 HTTP 请求体、上传文件或消息队列，直接调用 io.ReadAll(r) 会持续读取到 EOF。只要对端迟迟不结束，或者内容远大于预期，返回的 []byte 就可能不断增长。更稳妥的做法是先用 io.LimitReader 包住输入，再调用 io.ReadAll；读取结束后额外探测一个字节，才能判断内容是否真的超出上限。

官方文档：https://pkg.go.dev/io

把“最大允许内容长度”设为 maxBytes 时，先让 LimitReader 只交付这部分数据，再从原始 Reader 探测一个字节。探测到数据就返回超限错误；探测到 EOF 才表示输入没有超过上限。

先看 ReadAll 为什么会放大内存风险

io.ReadAll 的语义是从 Reader 读到 EOF，并返回已经读到的全部数据。它不会根据业务猜测“合理大小”，所以输入边界必须由调用方提供。仅仅在读取完成后检查 len(data) 已经晚了：过大的内容可能已经被放进内存。

package main

import (
    "fmt"
    "io"
    "strings"
)

func main() {
    input := strings.NewReader(strings.Repeat("x", 8*1024*1024))
    data, err := io.ReadAll(input) // 没有上限时，会一直读到 EOF。
    if err != nil {
        panic(err) // 底层读取失败不能被当成普通空内容。
    }
    fmt.Println(len(data)) // 检查长度发生在分配之后，不能阻止前面的内存增长。
}

这个模式适合输入大小已经被其他层严格保证的场景。面对不可信输入，边界应该放在 ReadAll 之前，让 Reader 在读取阶段就停止。

用 LimitReader 设置读取边界

io.LimitReader(r, n) 返回一个新的 Reader，最多从原始 Reader 交付 n 个字节。达到这个数量后，它会表现为 EOF；如果原始 Reader 更早结束，也同样会表现为 EOF。因此，下面的写法能限制保存到 []byte 的内容，但单看结果无法知道输入是“刚好 n 字节”还是“超过了 n 字节”。

package main

import (
    "fmt"
    "io"
    "strings"
)

func main() {
    const maxBytes = 1024
    input := strings.NewReader(strings.Repeat("g", 4096))

    limited := io.LimitReader(input, maxBytes) // 先截断交给 ReadAll 的数据范围。
    data, err := io.ReadAll(limited)
    if err != nil {
        panic(err) // 真正的底层读取错误仍然需要向上返回。
    }
    fmt.Println(len(data)) // 最多是 maxBytes，但这里还不能判定是否超限。
}

这里的“限制最大内存”要准确理解：返回的正文最多保留 maxBytes 字节，但 Go 运行时还会有切片扩容、调用栈和一字节探测等少量额外开销。它解决的是避免把整条不受控输入完整收进内存，而不是给整个进程设置硬性的 RSS 上限。

用一字节探测判断是否超限

如果业务需要拒绝超大内容，不能把 io.LimitReader 返回的 EOF 直接当作“输入正常结束”。可靠的判断方法是：先从原始 Reader 读取最多 maxBytes 字节，再从原始 Reader 读取一个字节。第二次读到数据，说明输入至少还有一个字节，应该返回超限错误；第二次读到 io.EOF，才说明正文刚好没有超过上限。

package main

import (
    "errors"
    "fmt"
    "io"
    "strings"
)

var ErrTooLarge = errors.New("input exceeds maximum size")

func readAtMost(r io.Reader, maxBytes int64) ([]byte, error) {
    if maxBytes  0 {
        return nil, ErrTooLarge // 还有数据，说明原始输入超过了上限。
    }
    if probeErr == io.EOF {
        return data, nil // 原始输入在上限内正常结束。
    }
    if probeErr != nil {
        return nil, fmt.Errorf("probe input boundary: %w", probeErr) // 探测阶段的 I/O 错误也要保留。
    }

    // 某些 Reader 允许 n=0 且 err=nil，继续读一次避免误判为 EOF。
    return data, nil
}

func main() {
    data, err := readAtMost(strings.NewReader("small payload"), 1024)
    fmt.Printf("data=%q err=%v\n", data, err) // 调用方只接收上限内的正文。
}

需要注意 Reader 的契约：一次 Read 可能返回 n > 0 同时带有非空错误，因此探测时应先判断 n > 0，不能只看错误值。对于遵守常见 Reader 约定的实现，n == 0 且 err == nil 很少见；若自定义 Reader 允许这种返回，生产代码可以循环探测，直到得到数据或确定性错误。

把 EOF 和底层错误分开处理

在循环读取的代码里，io.EOF 表示没有更多数据，不等于失败；但在这里，LimitReader 产生的 EOF 也可能只是“达到人为上限”。所以要先明确 EOF 来自哪一层：有限 Reader 的 EOF 只结束第一阶段，原始 Reader 的 EOF 才能证明没有超限。

func readAllWithLimit(r io.Reader, maxBytes int64) ([]byte, error) {
    limited := io.LimitReader(r, maxBytes) // 第一阶段只读取允许保留的正文。
    data, err := io.ReadAll(limited)
    if err != nil {
        return nil, err // 读取有限部分时出现非 EOF 错误，直接返回。
    }

    var one [1]byte
    n, err := r.Read(one[:]) // 第二阶段必须读取原始 Reader 的剩余内容。
    if n > 0 {
        return nil, ErrTooLarge // 有剩余数据，才是确定的超限。
    }
    if err == io.EOF {
        return data, nil // 原始 Reader 到 EOF，输入没有超过上限。
    }
    if err != nil {
        return nil, err // 保留探测阶段的真实 I/O 错误。
    }
    return data, nil // 兼容返回 0,nil 的 Reader；复杂实现可改成循环探测。
}

如果输入来自 http.Request.Body，业务层仍然要负责关闭 Body；这个函数只解决读取长度和错误判断，不替代资源生命周期管理。若协议本身提供了可信的 Content-Length，可以提前拒绝明显超限的请求，但不能只依赖它，因为流式传输可能没有这个值或值并不可靠。

常见误区与速查

• 只检查 len(data) > maxBytes：如果先用无界 ReadAll，检查时已经承担了过大的内存分配。
• 把有限 Reader 的 EOF 当成正常结束：达到 LimitReader 的上限也会返回 EOF，必须回到原始 Reader 探测。
• 用 maxBytes + 1 直接读取：这是另一种简单方案，会把一个额外字节暂存在结果里；若希望返回正文严格不超过上限，可以采用本文的一字节探测方式。
• 忽略 n > 0 与错误同时出现：Reader 可能先交付数据，再报告错误，判断顺序应先看已读字节数。

最终可以记住一条边界：io.LimitReader 负责把 ReadAll 的正文读取限制在上限内，原始 Reader 的一字节探测负责回答“上限后还有没有数据”。两步配合，才能同时控制内存和正确拒绝超限输入。

相关问题

LimitReader 会关闭底层 Reader 吗？不会。它只是包装读取范围；如果底层对象实现了 io.Closer，关闭责任仍由调用方承担。

为什么不直接使用 maxBytes+1？可以这样做并根据返回长度判断超限；本文使用一字节探测，是为了让最终返回的正文最多保留 maxBytes 字节。

ReadAll 读到上限后返回的 EOF 是错误吗？不是。对有限 Reader 来说这是正常的结束信号，是否超限要结合原始 Reader 的后续探测结果判断。