Go io.LimitReader 怎样限制请求体并保留超限判断

限制 Go HTTP 请求体时，io.LimitReader 只解决一半问题：它能让后续读取最多拿到指定字节数，但到达上限后同样会返回 io.EOF，单看读取结果并不能证明请求体没有更多内容。实用做法是先读取上限内数据，再从原始 Reader 额外读取一个字节；读到字节就判定超限，读到 EOF 才允许继续解析。

LimitReader 的上限边界：它截断读取，不替你判断请求是否合法

官方文档把它描述为“从 r 读取，但 n 个字节后停止并返回 EOF”。实现基础是 io.LimitedReader：它保存底层 Reader 和剩余字节数 N，每次读取都会减少 N。也就是说，限制器知道“最多给调用方多少”，不知道原始输入是否还有剩余内容。

先读取上限内内容，再保留超限证据

下面的辅助函数把最大值设为 1 MiB。关键点是读取器分成两条引用：有限 Reader 负责控制内存增长，原始 Reader 负责判断是否还有第 1 个额外字节。

package main

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

var ErrBodyTooLarge = errors.New("request body exceeds limit")

func readBodyWithin(r io.Reader, maxBytes int64) ([]byte, error) {
    // 有限读取器只暴露 maxBytes 个字节，避免直接 ReadAll 无界增长。
    limited := io.LimitReader(r, maxBytes)
    body, err := io.ReadAll(limited)
    if err != nil {
        // 底层读取错误不能被“达到上限”这个现象覆盖。
        return nil, fmt.Errorf("read limited body: %w", err)
    }

    var probe [1]byte
    // 从原始 Reader 探测一个额外字节，区分刚好达到上限和真正超限。
    n, probeErr := r.Read(probe[:])
    if n > 0 {
        return nil, ErrBodyTooLarge
    }
    if probeErr != nil && !errors.Is(probeErr, io.EOF) {
        // 探测阶段的网络或设备错误仍需交给上层处理。
        return nil, fmt.Errorf("probe body tail: %w", probeErr)
    }
    return body, nil
}

调用方应遵循 Go Reader 的约定：如果一次 Read 同时返回 n>0 和非空错误，要先处理这 n 个字节。因此探测逻辑不能只写成 if probeErr == nil；某些 Reader 可能把最后一个字节和 EOF 一起返回。

为什么“再读一个字节”比检查 len(body) 更可靠

len(body) == maxBytes 只能说明有限 Reader 交付了上限大小的数据，不能说明请求体是否刚好结束。短请求会小于上限，刚好相等的请求会等于上限，而更大的请求也会被截成同样的长度。真正有区分度的证据是原始 Reader 是否还能交付一个字节。

放进 HTTP 处理器时的兼容注意

在 HTTP 服务中，先保存原始 r.Body，把上限交给读取函数；处理结束后关闭请求体。若已经确定接口上限，也可以同时设置服务器级读取超时或检查 Content-Length，但不要只相信客户端提供的长度头，因为分块传输可能没有它。

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    defer r.Body.Close() // 释放请求体相关资源。

    body, err := readBodyWithin(r.Body, 1

这里的边界很明确：LimitReader 不负责超时、连接复用、JSON 深度、字段数量或文件落盘策略。若目标是流式保存大文件，应把有限 Reader 接到目标 Writer，并单独记录写入字节数；若目标是拒绝超限请求，则保留原始 Reader 的额外字节探测。

常见问题

达到 LimitReader 的 n 后一定会返回 EOF 吗？

对限制器来说，N 小于等于 0 时会以 EOF 结束；这只表示限制器不再提供数据，不等于底层 Reader 已经结束。

为什么不直接用 io.ReadAll(r) 再检查长度？

那会先把全部输入读入内存，失去限制读取的意义。应先用 LimitReader 控制读取，再用原始 Reader 探测一个字节。

Content-Length 已经超过上限，还需要 LimitReader 吗？

仍建议保留读取边界，因为请求可能使用分块传输，或长度头与实际输入不一致。两者是提前拒绝和读取兜底的不同层次。

把“读取最多多少”和“输入是否还有更多”拆成两个判断，才能让 io.LimitReader 在请求体处理中既节省内存，又保留超限决策所需的证据。