Go io.LimitReader 读取到上限后为什么没有 Err

我第一次用 io.LimitReader 给上传内容加大小上限时，看到读取到限制后返回的是 EOF，而不是“内容超限”错误，直觉上很容易以为判断漏了。其实这正是它的契约：LimitReader 只负责把可读范围截到 n 字节，读完这个范围就用正常结束信号 EOF 停止，并不会替你判断底层输入是否还有更多内容。

如果需求是“最多读这么多，超过就拒绝”，不要把 EOF 当成超限证据。最稳妥的办法是让探测上限变成 limit+1：最多多读一个字节，读到这个额外字节才判定真正超限。

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

为什么 LimitReader 读到上限后没有 Err

io.LimitReader(r, n) 返回一个新的 io.Reader。它内部记住一个剩余数量，调用者每次读取多少，就从剩余数量里扣除多少；剩余数量为零后，后续读取返回 0, io.EOF。这个 EOF 表示“包装器已经没有更多数据可提供”，不是“原始输入一定结束”，更不是一个专门的超限错误。

这样设计是因为 io.Reader 本身只约定返回已读字节和读取错误。限制器并不知道调用者把它用于“安全截断”“只取前缀”还是“严格拒绝过大输入”，因此它不能擅自把达到上限解释成失败。

package main

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

func main() {
	// 原始输入有 10 个字节，但包装器只暴露前 4 个字节。
	r := io.LimitReader(strings.NewReader("0123456789"), 4)
	buf := make([]byte, 8)

	for {
		n, err := r.Read(buf)
		// 先处理本次已经读到的字节，再判断 err 的含义。
		if n > 0 {
			fmt.Printf("读取 %d 字节：%q\n", n, buf[:n])
		}
		if err == io.EOF {
			// 这里表示限制范围已经读完，不代表原始输入没有第 5 个字节。
			break
		}
		if err != nil {
			panic(err)
		}
	}
}

这个例子里，第四个字节之后的 EOF 只说明 LimitReader 的可见范围结束。原始字符串是否还有第五个字节，单靠这个 EOF 无法判断。

用 limit+1 判断输入是否真的超限

严格限制输入大小时，读到前 limit 个字节还不够，因为“刚好等于上限”和“超过上限但被截断”会得到同样的前缀。可以把读取窗口扩大一个字节：

package main

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

// readAtMost 判断输入是否超过 limit，并只保留允许的前缀。
func readAtMost(r io.Reader, limit int64) (data []byte, tooLarge bool, err error) {
	if limit >1) {
		return nil, false, fmt.Errorf("limit 太大，无法构造 limit+1 探测窗口")
	}

	// 多读一个字节只用于判断超限，ReadAll 的内存上限是 limit+1。
	probe, err := io.ReadAll(io.LimitReader(r, limit+1))
	if err != nil {
		return nil, false, err
	}
	if int64(len(probe)) > limit {
		// 第 limit+1 个字节已经证明输入更长，返回前缀供调用方决定是否丢弃。
		return probe[:limit], true, nil
	}
	return probe, false, nil
}

func main() {
	data, tooLarge, err := readAtMost(strings.NewReader("abcdef"), 4)
	if err != nil {
		panic(err)
	}
	// tooLarge 为 true，data 仍然只有允许的前 4 个字节。
	fmt.Printf("data=%q tooLarge=%v\n", data, tooLarge)
}

判断条件应该看“是否读到了第 limit+1 个字节”，而不是把 EOF 当作错误。空输入和刚好四个字节都会正常结束且 tooLarge=false；五个或更多字节才会标记为超限。

三类读取任务不要混用

例如协议头或定长二进制块，应优先考虑 io.ReadFull，因为它表达的是“必须完整拿到”；日志摘要或预览只需要前缀时，io.LimitReader 更直接；上传、消息体和配置导入这类输入通常要拒绝超限，就应额外做一个字节的探测。

几个容易误判的边界

刚好达到上限

输入长度等于 limit 时，limit+1 探测读不到额外字节，得到正常 EOF，应该判定为合法，而不是超限。

底层 Reader 自己报错

LimitReader 不会吞掉底层的非 EOF 错误。网络断开、文件读取失败或自定义 Reader 返回的错误，仍然需要按错误处理；只有用于表示正常结束的 EOF 不应自动升级成失败。

limit 为零或负数

非正上限意味着包装器没有可读字节，读取会立即结束。业务层应在进入读取前明确限制值是否合法，避免把“配置成零”误解成“读取成功但内容为空”。

最后记住这条判断线

io.LimitReader 的职责是限制可读范围，不负责判断原始输入是否超限，所以读满上限后返回 EOF 是正常设计。只要业务要求“超过就拒绝”，就读取 limit+1 个字节：没有额外字节是刚好达到上限，出现额外字节才是真正超限；如果还要验证固定长度，则换用 io.ReadFull 或 io.ReadAtLeast，不要让一个 API 同时承担不同语义。

相关问题

• 为什么 LimitReader 返回的 EOF 不能直接当成上传失败？ 因为它代表包装器的可读范围结束，无法证明原始输入已经结束。
• 如何只保留前 limit 个字节又识别超限？ 用 io.LimitReader(r, limit+1)，读到第 limit+1 个字节后只保留前缀并拒绝后续处理。
• 什么时候应该用 ReadFull？ 当协议或文件格式要求必须完整读够固定字节数时。