Go io.ReadAll 怎样配合 LimitReader 防止无界读取

把小文件或外部响应整体读进内存时，不能只写 io.ReadAll(r)。可先包一层 io.LimitReader，再读取“业务上限加一字节”，随后按长度拒绝超限输入。只按上限截断会丢失“后面是否还有内容”的信息，err 为 nil 也不能证明原始输入完整。

下面用一个“小型配置导入”场景说明这种封装：允许的正文最大为 1 MiB，超限就拒绝，不接受截断后的配置。示例是原创教学代码，未在本文中运行；限制的是字节数量，不是耗时、字符数或整个进程的内存峰值。

先确定单次读取的字节预算

需要保护的资产是导入处理器的单次缓冲预算。风险来自调用方把长度未知的 Reader 交给整体读取函数，而不是某个文件扩展名。预算应来自本服务能够接受的对象大小，不能原样信任输入自报的长度。

本例允许调用方设置 0 到 8 MiB 的 max，实际导入可传入 1

LimitReader 的 EOF 不代表原始数据结束

io.LimitReader(r, n) 提供一个受限 Reader，累计达到 n 字节后对外表现为 EOF。io.ReadAll 遇到 EOF 正常结束并返回 nil 错误；真正的底层读取错误则仍可能返回。两者组合只约束该包装器可交付的内容，并不生成专门的“超过大小”错误。Go 官方 io 文档说明了这两项契约。

如果只读取 max 字节，长度等于 max 的结果有两种解释：原始输入恰好结束，或包装器先用完额度。不能拿 err == nil、len(b) == max 或包装器产生的 EOF 证明第一种解释。LimitedReader 由底层 Reader 与剩余额度组成，ReadAll 的结果则包括字节切片和错误。

用上限加一字节识别超限

对“超限拒绝”而非“只取前缀”的需求，把读取额度设成 max+1：读到这一额外字节就足以确认超限，无须读完剩余正文。ReadSmall 负责实施该契约，ErrTooLarge 是可分类的业务错误。

package bounded

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

// ErrTooLarge 表示输入超出允许的字节数。
var ErrTooLarge = errors.New("输入超过读取上限")

// ReadSmall 限定到适合本业务的小对象；不负责关闭输入。
func ReadSmall(r io.Reader, max int64) ([]byte, error) {
    // 业务硬上限既限制分配规模，也避免 max+1 溢出。
    const ceiling int64 = 8  ceiling {
        return nil, fmt.Errorf("读取上限必须位于 0 到 %d 字节", ceiling)
    }
    // 多读取一个字节，用于区分恰好达到上限与真正超限。
    b, err := io.ReadAll(io.LimitReader(r, max+1))
    if int64(len(b)) > max {
        // 已有超限证据时拒绝正文；本封装约定超限优先。
        return nil, ErrTooLarge
    }
    if err != nil {
        // 不把读取失败之前的部分正文交给业务解析。
        return nil, fmt.Errorf("读取输入失败: %w", err)
    }
    return b, nil
}

例如 max 为 4 时，空串和四字节输入可以接受，五字节输入会被拒绝。超过五字节的内容仍只需要在此包装器上取得前五字节便可拒绝。这里比较的是 []byte 的长度，中文字符的数量不能直接当作 UTF-8 字节预算。

注意，这个约束不是“最多只分配 max+1 字节”：ReadAll 的切片容量、临时分配、调用方已有数据以及底层 Reader 内部缓冲都可能产生额外开销。它解决的是无界累积读取，不承诺精确的进程内存峰值。

把读取错误与超限分开处理

封装的优先级是：配置非法先拒绝；已取得超限证据时返回 ErrTooLarge；未超限但发生底层错误时保留错误链；其余情况交付完整结果。若最后一次读取同时提供数据和非 EOF 错误，ReadAll 可能同时返回字节和错误。本例在长度已超限时优先报告大小问题，这是明确的业务选择，不是底层错误从未发生。

输入归调用方管理。LimitReader 不会替底层文件或响应体调用 Close；不要因为拿到一个 io.Reader 就丢掉原始资源的关闭责任。如果原始源随后还要继续读取，需要记住拒绝时已消耗至多 max+1 字节，不能当成从未触碰过流。

大小限制也不会让一个迟迟不返回的 Read 自动结束。对网络输入应由相应客户端、连接或上层协议单独设置超时与取消策略；不要把字节额度误当成时间限制。本节只界定责任，不展开其他防护实现。

日志记录预算和结论，不记录正文

导入失败时，日志保留操作标识、配置上限、错误分类即可；不要把配置正文或可能携带凭据的内容打进日志。对超限情况只能说“已观察到超过 max”，不能把 max+1 当作原始数据的总大小。

ReadSmall 返回 nil 正文以减少误用风险。调用方应先检查 error，再解析数据；不能在有错时继续用某个截断片段覆盖原配置。如果需要同时记录底层错误和超限证据，应另行设计结构化错误类型，不要偷偷改变此封装的优先级。

围绕临界长度检查调用契约

接入前可用可控 Reader 检查以下预期。这是读者可执行的检查清单，不是本文的测试报告：

• 输入长度为 0、max-1 和 max，且正常结束：成功返回原始字节。
• 输入长度为 max+1 或更大：返回 ErrTooLarge，不交付截断正文。
• max 为 0：空输入成功，非空输入拒绝。
• 长度尚未超限但底层读失败：保留可追溯的读取错误。
• max 为负数或超过 8 MiB：配置错误，不消费输入。

为什么读到 max 字节后不能直接当作超限？

因为恰好 max 字节是允许的。需要额外一个字节作为“确实更多”的证据；反过来，只读 max 字节也不能证明原始源完整。

只想预览文件开头，还需要加一吗？

若业务契约本来就是读取前缀而非验证总长度，可以只限定前缀长度，但必须把结果叫作预览，不得冒充完整文件。

很大的合法对象该怎么办？

整体读取未必合适。应考虑流式处理及相应的总量控制，避免仅仅把 max 调得很大。本文的封装适合预算明确的小对象。

关键取舍只有一个：需要拒绝超限时，多读一字节并明确分类；需要截取前缀时，承认截断语义。两者不能混用。