Go io.LimitedReader 怎样限制下游最多读取多少字节

我在处理上传流时遇到过一个很容易被忽略的边界：业务只允许读取前 8 MiB，但下游函数拿到的仍然是一个普通的 io.Reader。这时最直接的做法是用 io.LimitReader 包住原始输入，让限制发生在下游真正读取的位置。

结论：io.LimitReader(r, n) 会返回一个最多提供 n 个字节的 Reader。达到上限后，它返回 io.EOF；它不会自动关闭底层 Reader，也不会告诉你“EOF 是自然结束还是刚好撞上上限”，所以调用方要结合已读字节数和剩余输入责任来判断。

如果目标只是给解析器设置硬上限，用 LimitReader；如果还要观察剩余配额，就保留 *io.LimitedReader 并读取它的 N 字段。

先把“最多读取多少”放在下游边界

Go 官方 io 包把 LimitReader 定义为：从原始 Reader 读取，但在 n 个字节之后停止。它返回的底层实现是 *io.LimitedReader，其中 R 保存原始 Reader，N 保存尚未允许返回的字节数。

这和先把整个输入读进内存再截断不同。限制器把上限放在数据流入口，解析器、复制函数或自定义处理函数看到的都只是受限视图。尤其是请求体、压缩包头部或不可信文件，应该先限制再交给下游。

用 LimitReader 包住原始 Reader

下面的示例把输入限制在 8 个字节，再让下游按普通 Reader 读取。代码只演示限制语义，不会关闭底层输入；如果原始对象实现了 io.Closer，关闭责任仍由拥有它的代码承担。

package main

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

func readHeader() error {
    source := strings.NewReader("header=ok;payload=secret")
    limited := io.LimitReader(source, 8)

    // 下游只看见最多 8 个字节，避免把后续 payload 交给解析器。
    data, err := io.ReadAll(limited)
    if err != nil {
        // ReadAll 的错误仍可能来自原始 Reader，不能把所有错误都当成上限命中。
        return fmt.Errorf("读取受限输入失败: %w", err)
    }

    // 这里的结果是 header=，因为受限 Reader 只允许返回 8 个字节。
    fmt.Printf("%s\\n", data)
    return nil
}

func main() {
    if err := readHeader(); err != nil {
        fmt.Println(err)
    }
}

示例中的 limited 只是视图，不是新的文件句柄。若 source 是 HTTP 响应体或打开的文件，仍要在创建它的那一层负责 Close。

达到上限时，怎么判断到底发生了什么

LimitedReader.Read 每次成功读取后都会减少 N。当 N 时，下一次读取直接返回 0, io.EOF；如果底层 Reader 自己先返回 EOF，限制器也会把这次结束传出来。因此“读到了 EOF”本身不能说明输入一定达到了上限。

需要区分的判断可以整理成下面这样：

如果业务要求“必须完整拿到固定长度”，不要只看 err == nil。可以用 io.ReadFull 读取受限视图，并把 io.ErrUnexpectedEOF 当成输入不完整来处理：

func readExactly(r io.Reader, limit int64) ([]byte, error) {
    limited := io.LimitReader(r, limit)
    buf := make([]byte, limit)

    // ReadFull 会持续读取，直到填满缓冲区或遇到明确错误。
    n, err := io.ReadFull(limited, buf)
    if err != nil {
        // n 小于 limit 时，区分输入提前结束和底层真实错误。
        return buf[:n], fmt.Errorf("固定长度输入不完整: 已读 %d/%d: %w", n, limit, err)
    }
    return buf[:n], nil
}

这里的 limit 来自可信的协议或配置时才适合直接用于 make；如果它来自请求参数，还应先做整数范围和内存预算控制。限制流量和限制内存是两个不同动作。

别把限制器当成会关闭输入的 Closer

一次排查中，问题并不在字节上限，而在代码把 io.LimitReader 的返回值当成了可关闭对象。它的返回类型是 io.Reader，限制读取和释放底层资源是两件事。文件、响应体、连接等资源必须由真正持有它们的代码关闭。

func copyLimited(dst io.Writer, src io.ReadCloser, max int64) error {
    defer src.Close() // 原始资源由本函数持有，因此在这里负责释放。

    limited := io.LimitReader(src, max)
    _, err := io.Copy(dst, limited)
    if err != nil {
        // 复制错误可能来自源或目标，直接向上保留上下文。
        return fmt.Errorf("复制受限数据失败: %w", err)
    }
    return nil
}

如果读取刚好达到 max 后还要继续消费同一条输入，保留原始 src，不要试图从 limited 中“恢复”剩余数据。限制器只会阻止它继续向下游提供字节，原始 Reader 的位置已经随着实际读取推进。

最后用三句话收住这个边界

• 用 io.LimitReader 把字节上限放在下游读取边界，不必先把全部输入放进内存。
• 处理 n > 0 后再看错误；达到上限、输入提前 EOF 和底层错误不能混为一谈。
• 限制器不负责关闭原始 Reader；资源归谁拥有，就由谁负责关闭。

相关问题

io.LimitedReader 和 io.LimitReader 有什么区别？后者是构造函数，返回 io.Reader；前者是具体结构体，可以直接读取和调整 N，但应谨慎修改其状态。

达到上限后为什么看到 io.EOF？这是限制器对下游的正常结束信号；它不等于原始输入已经结束，是否命中上限要结合已读字节数和原始 Reader 的后续责任判断。