Go io.LimitReader 读取超限内容时怎样判断是否被截断

我在处理上传内容和响应体时遇到过一个很容易误判的边界：给读取器套上 io.LimitReader 后，读取结果到达上限并返回 EOF，到底代表内容刚好这么长，还是后面其实还有数据？答案是：只看受限读取器的 EOF 分不出来。要判断是否超限，应当把读取上限设为 limit+1，多读一个哨兵字节；如果拿到了第 limit+1 个字节，就能确定源数据超过限制。

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

下面把这个判断拆成小内容读取和大内容流式复制两种写法，重点是区分“完整”“恰好达到上限”和“确实被截断”三个结果。

为什么只看 EOF 判断不了是否超限

io.LimitReader(r, n) 返回一个新的读取器，它最多从底层 r 提供 n 个字节。它的职责是限制当前读取视图，并不负责告诉调用方底层源是否还有剩余内容。

因此，源数据长度为 100 字节、限制为 100 字节时，读取结束会得到 EOF；源数据长度为 101 字节、限制仍为 100 字节时，受限读取器同样会在提供 100 字节后得到 EOF。EOF 只说明这个受限视图已经没有更多可读内容，不能直接当成“源数据完整”的证据。

如果直接写成 io.ReadAll(io.LimitReader(src, limit))，最多只能得到一个长度不超过限制的切片。长度等于限制时，仍然有两种可能：

小内容读取：多读一个哨兵字节

对于配置文件、短消息或有明确内存预算的小请求，可以把上限提高一个字节。读到的内容长度不超过原始限制时，说明源数据没有超过限制；读到 limit+1 个字节时，说明源数据确实更长。多出的这个字节通常只用于作出拒绝判断，不必交给后续解析器。

package main

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

// readAtMost 用一个哨兵字节区分“恰好到上限”和“超过上限”。
func readAtMost(src io.Reader, limit int64) ([]byte, bool, error) {
    if limit >1) {
        return nil, false, fmt.Errorf("读取上限过大，无法增加哨兵字节")
    }

    // 多读一个字节：多出的字节只用来判断是否超限。
    data, err := io.ReadAll(io.LimitReader(src, limit+1))
    if err != nil {
        return nil, false, err
    }
    truncated := int64(len(data)) > limit
    if truncated {
        // 调用方可以直接拒绝，不把超限内容交给业务解析。
        return data[:limit], true, nil
    }
    return data, false, nil
}

func main() {
    data, truncated, err := readAtMost(strings.NewReader("0123456789"), 8)
    if err != nil {
        fmt.Println("读取失败:", err)
        return
    }
    fmt.Printf("内容=%q，是否超限=%v\n", data, truncated)
}

这个函数有三个关键点。第一，判断条件是结果长度是否大于原始 limit，不是判断 err == io.EOF。第二，源数据刚好等于限制时，读取结果长度是 limit，不会被误判为超限。第三，超限时只保留前 limit 个字节返回，避免把哨兵字节意外交给业务层。

如果限制值来自外部请求参数，还要在进入 limit+1 前先检查非负数和整数上溢。实际业务中通常会把允许的最大值设得远小于 math.MaxInt64，这样错误路径更容易控制。

大内容不要 ReadAll：用 io.Copy 判断流式超限

当输入可能达到几十 MB 或更大时，ReadAll 会把受限内容暂存到内存。此时可以让 io.Copy 把数据直接写入目标文件、哈希计算器或临时缓冲区，同时把 LimitedReader 的额度设为 limit+1。最终用复制字节数是否大于原始限制判断超限。

package main

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

// copyAtMost 把数据写入 dst，并通过多出的一个字节识别超限。
func copyAtMost(dst io.Writer, src io.Reader, limit int64) (int64, bool, error) {
    if limit >1) {
        return 0, false, fmt.Errorf("读取上限过大，无法增加哨兵字节")
    }

    // LimitedReader 只允许向下游多写一个哨兵字节。
    written, err := io.Copy(dst, &io.LimitedReader{R: src, N: limit + 1})
    if err != nil {
        // 底层网络或文件错误不能被“是否超限”结论掩盖。
        return written, false, err
    }
    return written, written > limit, nil
}

func main() {
    var sink strings.Builder
    written, truncated, err := copyAtMost(&sink, strings.NewReader("0123456789"), 8)
    if err != nil {
        fmt.Println("复制失败:", err)
        return
    }
    fmt.Printf("写入=%d，是否超限=%v\n", written, truncated)
}

流式版本的结论更简单：written 表示没有读出超限字节，written > limit 表示源数据至少还有一个字节超出限制。对于上传场景，可以在发现超限后关闭临时文件并返回 413；对于需要保留文件的场景，也可以先写入隔离位置，确认未超限后再移动到正式路径。

几个容易混淆的边界

限制为零时会怎样

限制为 0 时，哨兵上限是 1。空输入读不到字节，判定为未超限；只要源输入至少有一个字节，就能读到哨兵并判定为超限。这个行为很适合表达“只允许空内容”，但要确认它确实是业务意图。

底层 reader 返回错误时不要只看长度

io.ReadAll 和 io.Copy 都可能在拿到部分数据后返回底层错误。部分数据长度小于限制，不代表数据完整；部分数据长度达到限制，也不代表可以安全接受。应先处理非 EOF 的错误，再根据读取数量判断是否触达超限。这里的 EOF 是正常结束信号，不需要当成失败。

需要继续消费剩余内容时，别误以为 LimitReader 会自动恢复

哨兵字节已经从底层 reader 读出。如果后续逻辑还要继续消费原始流，必须把这个字节保存并与剩余 reader 拼接，或者改用带缓冲的读取器先窥视。多数上传限制场景在发现超限后会直接拒绝并关闭流，因此丢弃哨兵字节正是预期行为。

我会怎样选择实现

短内容的判断优先使用 limit+1 加 io.ReadAll，代码短且结果容易传递；大内容则使用 io.Copy 加 io.LimitedReader，把内存占用交给目标 writer 控制。两种方式的共同原则是：不要把受限 reader 返回的 EOF 当作源数据完整性的证明。

相关问题

io.LimitReader 会返回“超限错误”吗？不会。它把可读视图限制在指定字节数内，达到上限后表现为读完；是否超限需要调用方通过哨兵读取自己判断。

为什么不能把读到 limit 字节直接当成超限？因为源数据刚好等于 limit 时也会读到同样的长度，必须再尝试读取一个字节。

超限时应该保留多出来的那个字节吗？如果业务会拒绝整个输入，通常丢弃即可；如果还要继续解析同一条流，就要保存它，不能让下游悄悄少一个字节。

总结一下：io.LimitReader 解决的是“最多给我多少字节”，不是“源数据是否完整”。把读取额度设成 limit+1，再用结果长度或复制字节数和原始限制比较，就能可靠识别截断；小内容用 ReadAll，大内容用 io.Copy，底层错误则始终优先处理。