Go io.LimitReader 怎样区分读完原文还是碰到长度上限

先给结论：io.LimitReader 返回的 EOF 不能单独证明“原文已经读完”。底层读取器自然返回 EOF，或者包装器把剩余额度读到 0，都可能让调用方看到 EOF。

如果业务只是防止无界读取，可以直接使用 io.LimitReader。如果业务还要判断“输入是否超过上限”，更稳妥的做法是把读取上限设为 limit+1：最多多取一个字节，长度超过 limit 就判定超限，长度不超过则说明输入没有超过限制。

官方资料：https://pkg.go.dev/io#LimitReader

先拆开 LimitReader 的返回语义

io.LimitReader(r, n) 返回一个 io.Reader，它从底层 r 读取，但最多提供 n 个字节。官方文档同时说明，它的底层实现是 *io.LimitedReader。

LimitedReader 有两个关键字段：R 是底层读取器，N 是剩余可读取字节数。每次成功读取后，N 都会减少；当 N，包装器会返回 EOF。

这解释了一个常见误区：err == io.EOF 只说明这次读取没有更多数据可交给调用方，不包含“为什么没有更多数据”的完整业务结论。

为什么单看 EOF 会误判

假设上限是 5 字节，有两种输入：

• 输入只有 3 字节：底层数据先结束，调用方最终得到 EOF。
• 输入有 20 字节：包装器只允许交付前 5 字节，额度用完后也会得到 EOF。

这两个结果的 err 可能完全相同。即使你能观察到 LimitedReader.N == 0，它也只能证明包装器已经消耗完自己的额度；如果原始输入恰好只有 5 字节，底层也可能正好在同一个边界结束。

因此，下面这种判断只能回答“包装器是否读满”，不能严格回答“底层是否还有第 6 个字节”：

package main

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

func main() {
    limit := int64(5)
    lr := &io.LimitedReader{
        R: strings.NewReader("abcde"),
        N: limit,
    }

    data, err := io.ReadAll(lr)
    // N 为 0 说明包装器额度耗尽，但不能证明原始输入超过了 limit。
    fmt.Printf("data=%q bytes=%d remaining=%d err=%v\n", data, len(data), lr.N, err)
}

这段代码适合观察状态，却不适合单独做“是否超限”的业务判定。

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

要判断输入是否超过业务上限，给包装器多留一个字节的探测空间即可。读取最多 limit+1 个字节后：

• 读取结果长度小于或等于 limit：输入没有超过上限。
• 读取结果长度大于 limit：输入至少还有一个字节超出业务上限。

package main

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

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

func readAtMostLimit(r io.Reader, limit int64) ([]byte, error) {
    if limit  limit {
        return nil, ErrTooLarge
    }
    return data, nil
}

func main() {
    data, err := readAtMostLimit(strings.NewReader("abcdef"), 5)
    // 这里会得到 ErrTooLarge；EOF 已被 ReadAll 作为正常结束处理。
    fmt.Printf("data=%q err=%v\n", data, err)
}

这个策略的关键不是把 EOF 换成另一个错误，而是提前把“是否存在第 limit+1 个字节”变成可观察事实。对于大文件或请求体，探测最多只多读一个字节，不需要把完整输入加载到内存。

流式复制时怎样保留错误语义

如果输入需要写入文件或下游连接，不要为了判断超限而直接使用无界的 io.ReadAll。可以使用 io.LimitReader(r, limit+1) 配合流式复制，并根据复制字节数判断是否超限：

package main

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

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

func copyAtMostLimit(dst io.Writer, src io.Reader, limit int64) (int64, error) {
    if limit  limit {
        // 超限数据已经写入下游，调用方应按策略清理临时结果。
        return limit, ErrTooLarge
    }
    return n, nil
}

func main() {
    var dst strings.Builder
    n, err := copyAtMostLimit(&dst, strings.NewReader("abcdef"), 5)
    // 这里会得到 ErrTooLarge，业务代码不应提交 dst 的内容。
    fmt.Printf("written=%d value=%q err=%v\n", n, dst.String(), err)
}

生产代码要提前决定超限后的下游处理：如果目标是临时文件，发现超限后应删除临时文件；如果目标是可复用缓冲区，应清空或丢弃本次结果。这里的“多读一个字节”是检测手段，不代表超限数据应该被提交。

别忘了输入资源的关闭责任

io.LimitReader 只实现 io.Reader，不会替你关闭底层资源。若来源是文件、HTTP 响应体或其他 io.ReadCloser，关闭动作仍然由调用方负责：

func consumeBody(body io.ReadCloser, limit int64) error {
    // 函数拥有 body 的生命周期，因此在所有返回路径上负责关闭。
    defer body.Close()

    _, err := readAtMostLimit(body, limit)
    return err
}

另外，读取接口约定调用方应先处理 n > 0 的数据，再判断 err。不要因为同一次调用返回了非空错误，就丢弃已经读到的字节。

最后的判断规则

一句话记忆：LimitReader 负责“最多给多少”，不负责告诉你“底层是否还有更多”。要做超限判断，就多读一个字节；要处理流式错误，就保留已读数据、传递非 EOF 错误，并明确资源关闭责任。

相关问题

为什么 LimitReader 读到上限后返回 EOF，而不是专门的超限错误？

它实现的是通用 io.Reader 语义，文档定义为达到额度后停止并返回 EOF。是否把这种结束解释为“截断”或“超限”，需要调用方用业务规则判断。

直接把 LimitReader 断言成 LimitedReader 可以吗？

当前标准库实现返回的是 *io.LimitedReader，但更清晰的做法是业务需要观察 N 时直接创建 io.LimitedReader。不要把隐藏的具体实现当成所有 Reader 包装器都具备的通用能力。

limit+1 会不会导致内存失控？

只要 limit 本身经过业务上限约束，探测最多比它多一个字节。对于超大上限仍应采用流式复制，并在发现超限后清理已写入的临时结果。