Go io.LimitReader 读取超出上限的数据怎样区分截断和正常 EOF

我在给请求体、导入文件或消息流设置大小上限时，最容易踩到的坑是把 io.LimitReader 返回的 EOF 当成“源数据已经自然结束”。实际上，LimitReader 在读满限制后也会主动返回 EOF，所以只把上限设为 max，无法区分“刚好 max 字节”和“源数据更长但被截到 max 字节”。

更稳妥的做法是把探测窗口设为 max+1：读到最多一个额外字节，长度超过 max 时返回明确的超限错误；没有读到额外字节时，再把底层的正常 EOF 与真实读取错误分开处理。

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

先确认 LimitReader 的 EOF 语义

io.LimitReader(r, n) 返回一个新的 Reader，它从底层 r 读取，但在输出 n 个字节后停止。官方实现使用 LimitedReader，其中 N 表示剩余可读取的字节数；当 N 或底层读取器返回 EOF 时，读取都会得到 EOF。

这意味着下面两种源数据在“限制为 max”时可能得到同一种结论：

• 源数据确实只有 max 字节，底层自然结束；
• 源数据超过 max 字节，但限制读取器在第 max 字节之后停止。

如果业务只需要“最多读 max 字节”，这种语义完全够用；如果业务还要拒绝超长输入，就必须额外探测一个字节。这里的关键不是给 EOF 换一个名字，而是让读取窗口保留足够的信息。

用 max+1 读取窗口识别超限

我会把“最大允许长度”和“探测窗口”分成两个概念。最大允许长度是 max，探测窗口是 max+1。读完后，长度小于或等于 max 表示没有观察到超限；长度达到 max+1 才说明源数据至少还有一个字节，应该拒绝。

下面的函数把长度超限定义成独立错误。它没有把所有 EOF 都转换成业务错误：只有成功读到 max+1 字节时才返回 ErrTooLarge，底层的其他错误则保留在错误链里。

package bounded

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

// ErrTooLarge 表示探测到的输入至少超过了允许长度。
var ErrTooLarge = errors.New("input exceeds limit")

// ReadAtMost 读取不超过 max 的完整内容，并识别是否至少还有一个额外字节。
func ReadAtMost(src io.Reader, max int64) ([]byte, error) {
	if max  max {
		// 额外字节只证明输入超限，返回前不继续消费源 Reader。
		return nil, ErrTooLarge
	}

	return data, nil
}

这个实现还有一个工程取舍：它在内存中保留最多 max+1 个字节，因此适合“需要拿到完整内容、同时设置上限”的场景。它不会继续消耗超限输入，调用方可以关闭连接、丢弃消息或选择其他协议层动作。

当 max 接近 math.MaxInt64 时，直接计算 max+1 还要考虑整数溢出。实际接口通常会给上限设置一个业务可接受的范围；如果上限来自外部配置，应在进入该函数前先做范围约束。

把底层错误与截断错误分开

io.ReadAll 可能同时拿到已经读取的部分数据和一个非空错误。Go 的 Reader 约定要求调用方先处理 n > 0 的数据，再判断错误；在这个“必须得到完整内容”的函数里，任何非空读取错误都会让本次结果失败，但错误原因仍应通过 %w 保留下来。

例如，底层网络流可能在只返回一部分内容后报错。此时不能因为数据长度小于 max，就把它当成一个合法的短输入；也不能把它统一改成 ErrTooLarge。长度问题和传输问题是两个不同的故障域：

覆盖空输入和边界测试

测试重点不是把实现再抄一遍，而是确认四个互相容易混淆的状态：空输入、恰好达到上限、超过上限，以及底层在中途失败。由于这里没有运行测试，下面只展示应当写进项目的测试形状和断言目标。

package bounded

import (
	"errors"
	"io"
	"strings"
	"testing"
)

// failReader 模拟已经读到部分内容后由底层返回固定错误。
type failReader struct {
	data []byte
	err  error
}

func (r *failReader) Read(p []byte) (int, error) {
	if len(r.data) == 0 {
		return 0, r.err
	}
	n := copy(p, r.data)
	r.data = r.data[n:]
	return n, nil
}

func TestReadAtMostBoundaries(t *testing.T) {
	tooLarge := errors.New("source unavailable")
	tests := []struct {
		name     string
		src      io.Reader
		max      int64
		wantData string
		wantErr  error
	}{
		{"空输入", strings.NewReader(""), 4, "", nil},
		{"恰好上限", strings.NewReader("abcd"), 4, "abcd", nil},
		{"超过上限", strings.NewReader("abcde"), 4, "", ErrTooLarge},
		{"底层错误", &failReader{data: []byte("ab"), err: tooLarge}, 4, "", tooLarge},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			got, err := ReadAtMost(tt.src, tt.max)
			if string(got) != tt.wantData {
				t.Fatalf("内容 = %q，想要 %q", got, tt.wantData)
			}
			if !errors.Is(err, tt.wantErr) {
				t.Fatalf("错误 = %v，想要可匹配 %v", err, tt.wantErr)
			}
		})
	}
}

这里的断言用 errors.Is 检查错误链，而不是比较包装后的字符串。需要注意，failReader 只是说明错误边界的测试替身，不代表某一种网络库的具体行为；真实 Reader 仍可能在同一次 Read 中返回“部分数据加错误”，调用方应继续遵守 Reader 契约。

按目标选择读取策略

如果你只想限制一次复制或转发的最多字节数，直接使用 io.LimitReader(src, max) 就足够了；此时业务不需要知道源数据是否更长。若你要把“超过上限”作为明确的拒绝条件，就使用 max+1 探测窗口，并在读到额外字节时返回专门错误。

如果输入很大、不能一次放入内存，则不要把上面的 io.ReadAll 机械搬过去。可以将 io.LimitReader(src, max+1) 接到分块解析器，再在累计长度达到 max+1 时停止；分块版本仍然需要保留底层读取错误，也要定义解析器已经消费了多少数据后才算超限。

最后不要把 io.LimitReader 误当成完整的上传安全方案。它解决的是读取量边界，不会替你判断格式、字符编码、压缩炸弹、业务字段大小或连接生命周期。把它放在正确的输入边界上，再由上层决定拒绝、清理和审计策略，结论才不会越过这个 API 的职责。

几个容易混淆的问题

读到 max 字节并返回 EOF，是不是说明输入没有超长？

不是。若限制窗口本身就是 max，源数据恰好 max 字节和源数据超过 max 都可能在这里结束。要判定超长，应至少读取到 max+1 个字节。

为什么不直接比较返回的错误是不是 io.EOF？

因为 EOF 既可能来自底层源，也可能来自 LimitedReader.N 归零。错误值本身没有携带“是谁让读取停止”的额外标记，窗口大小才是这里的判定信息。

超限时为什么不返回已经读到的前 max 个字节？

这是示例的安全取舍：一旦确认超限，就让调用方明确处理失败，避免上层误把被截断的内容当成完整文档。如果业务确实需要前缀摘要，可以单独设计返回值并把“截断”状态显式化。

底层读取错误能不能统一当作输入不完整？

不建议。超限是输入大小结论，底层错误可能是连接中断、文件权限或设备故障。保留错误链，调用方才能按不同原因重试、记录或回滚。

归纳起来，io.LimitReader 的 EOF 只说明这个受限读取器没有更多数据可交付，不自动说明源数据自然结束。只要业务需要识别超限，就把读取窗口扩大一个字节，并把长度结论与底层错误分别建模。