Go io.ReadAll 怎样限制内存占用

服务端读取请求体、配置文件或上传内容时，最容易被忽略的风险是把输入大小交给对方决定。io.ReadAll 会持续读取直到 EOF 或错误，并把已经读到的内容作为完整的 []byte 返回；输入越大，内存压力越直接。

如果业务确实需要完整字节切片，就先用 io.LimitReader 把最大字节数写进代码，再对“刚好读满上限”和“真正读到 EOF”做区分；如果业务只需要转发或逐块处理，则用 io.Copy 或固定缓冲区，避免把全文留在内存。

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

先看清 io.ReadAll 的内存边界

把一个 io.Reader 交给 io.ReadAll，得到的是完整内容，而不是一个受控大小的窗口。它适合小而可信的输入，例如一份体积有明确上限的内部配置；面对请求体或外部文件时，调用点必须先回答“最多允许读多少”。

package main

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

func main() {
	// ReadAll 会一直读取到 EOF；这里的输入很小，适合展示完整结果。
	data, err := io.ReadAll(strings.NewReader("配置内容"))
	if err != nil {
		// 读取中途的非 EOF 错误必须交给调用方处理。
		panic(err)
	}

	// 返回值是完整字节切片，后续解析前仍会占用这段内存。
	fmt.Println(string(data))
}

内存风险不是“调用了一个危险函数”，而是“完整内容的生命周期与输入大小绑定”。如果后面还要把 []byte 转成字符串、反序列化成结构体，峰值占用可能继续增加，所以限制应放在读取入口。

用 LimitReader 给完整读取加上上限

io.LimitReader 返回一个 Reader，在最多读取指定字节后返回 EOF。它可以和 io.ReadAll 组合，让最终的 []byte 有明确上限；但标准库把“到达上限”也表现为 EOF，因此如果业务必须拒绝超限输入，还要额外读一个字节做判断。

package main

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

var errTooLarge = errors.New("input exceeds limit")

func readAtMost(r io.Reader, limit int64) ([]byte, error) {
	// 多读一个字节，用来区分“刚好到达上限”和“确实已经结束”。
	limited := io.LimitReader(r, limit+1)
	data, err := io.ReadAll(limited)
	if err != nil {
		// 保留底层读取错误，不把它误报成大小超限。
		return nil, err
	}
	if int64(len(data)) > limit {
		// 超限时返回业务错误，调用方可以映射成 413 或自定义状态。
		return nil, errTooLarge
	}
	return data, nil
}

func main() {
	data, err := readAtMost(strings.NewReader("0123456789"), 8)
	fmt.Println(string(data), err) // 空内容，错误为 input exceeds limit
}

limit+1 很关键：只读到 limit 时，无法知道输入是正好结束，还是后面还有内容。多读一个字节不会把完整超大输入装进内存，却能让“拒绝超限”成为确定的业务分支。

不需要完整内容时改用流式读取

如果目标只是把输入写入文件、对象存储或另一个连接，就不要先生成完整的 []byte。io.Copy 会在 Reader 和 Writer 之间搬运数据，调用方只需要控制目标、错误和资源生命周期。

package main

import (
	"io"
	"os"
	"strings"
)

func copyToFile() error {
	// 创建输出文件后，无论复制成功还是失败都要释放文件描述符。
	dst, err := os.Create("payload.bin")
	if err != nil {
		return err
	}
	defer dst.Close()

	// LimitReader 把转存任务也限制在指定大小内，避免无限输入。
	src := io.LimitReader(strings.NewReader("stream data"), 1024*1024)
	_, err = io.Copy(dst, src)
	return err
}

流式方案不会把全文保留在一个返回切片里，但它不会自动替你处理“是否刚好达到上限”。需要拒绝超限时，可以在复制结束后再读取一个字节，或在业务层封装一个能够报告“触顶”的 Reader；不要仅凭 io.Copy 返回 nil 就断言输入没有超过限制。

按输入规模选择读取方案

选择方案时先问两个问题：后续逻辑是否真的需要全部字节，以及输入是否可能由用户、网络或外部文件控制。前者决定能否流式处理，后者决定是否必须加上限。把这两个问题写进函数接口，比在调用点临时猜测更稳妥。

常见问题

io.LimitReader 到达上限会返回什么？

它会在剩余字节数为零时返回 EOF。EOF 只说明这个受限 Reader 没有更多可读内容，不等于底层输入本来就在此处结束；需要拒绝超限时应多读一个字节。

io.ReadAll 出错时返回的数据要不要保留？

函数可能同时返回已经读到的部分数据和错误。若业务不能使用不完整内容，应优先处理错误并丢弃这段数据；只有协议明确支持断点或部分结果时，才把部分数据交给上层。

加了 LimitReader 就完全没有内存风险了吗？

没有。它只限制了这一次 Reader 能提供的字节数，后续解析、复制、字符串转换和并发请求仍可能放大峰值。上限要结合单请求预算和并发量一起设定。

最终的判断可以很简单：需要完整内容就限制后再读，需要搬运就流式复制，需要逐条处理就用固定缓冲区。这样内存上限、超限行为和错误处理都落在代码的可见边界里。