Go io.LimitReader 限制输入大小的组合方式

处理请求体、文件或消息流时，先给 io.Reader 加一层 io.LimitReader，再交给 io.ReadAll、io.Copy 或解析器，是最直接的输入上限方案。它按字节计数，读到上限后返回 io.EOF；如果业务还要判断“输入是否超过限制”，就把上限设为 limit+1，读完后再检查结果长度。

Go io.LimitReader 的上限到底限制了什么

它限制的是包装层能交给下游的字节数，不是把原始流永久截短，也不是按字符、行或 JSON 字段计数。传入负数时不会得到有意义的可读数据，因此上限应由业务配置校验为非负值。下面的例子把读取窗口设为“业务上限加一个探测字节”。

package main

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

func readAtMost(r io.Reader, limit int64) ([]byte, bool, error) {
    if limit  limit {
        return data[:limit], true, nil // 只保留上限内数据，并报告超限。
    }
    return data, false, nil
}

func main() {
    data, tooLarge, err := readAtMost(strings.NewReader("abcdef"), 4)
    fmt.Printf("data=%q tooLarge=%v err=%v\n", data, tooLarge, err)
}

这个组合的结果是 data="abcd"、tooLarge=true。如果输入只有四个字节，读取窗口会在自然 EOF 前结束，tooLarge 为 false。这里的 limit+1 只是探测，不应把多出来的字节交给后续解析。

EOF、超限和底层错误要分开处理

io.LimitReader 到达 n 字节后返回 EOF，所以“看到 EOF”本身只说明这一层没有更多数据，并不自动等于输入合法。对固定格式数据，读取长度不足时可以返回业务错误；对未知长度的上传或消息，则使用上面的探测字节判定超限。

实现自定义读取循环时，不要先判断 error 再丢弃本次数据。Go 的 Reader 约定允许一次返回 n>0 和一个错误，调用者应先消费这 n 个字节。对结构化数据中途结束的场景，可把普通 EOF 转换为更明确的 io.ErrUnexpectedEOF 或业务错误。

把限制器接到复制和解析流程

限制器实现了 io.Reader，因此不需要改造下游函数。复制文件片段时放在 io.Copy 前面；解析连续 JSON 对象时放在 json.Decoder 前面。这样限制策略集中在入口，消费者仍然只关心自己的格式。

// limitedCopy 只把上限内的数据写入目标，并保留复制错误。
func limitedCopy(dst io.Writer, src io.Reader, limit int64) (int64, error) {
    if limit 

示例中的第二个函数需要额外导入 encoding/json；生产代码还应根据协议要求限制单个对象大小，并在解码循环中把 EOF 当作正常结束、把其他错误当作失败。若要判断 JSON 输入是否在上限外仍有内容，可先用探测字节读入缓冲区，再把缓冲区与剩余 Reader 组合给解析器。

常见问题

io.LimitReader 会关闭底层文件或请求体吗？

不会。它只是 Reader 包装器，不提供 Close。谁创建或持有底层资源，谁负责在合适的位置关闭。

limit 为零时会读取一个字节吗？

直接使用 io.LimitReader(r, 0) 不会向下游提供数据；若采用“limit+1”探测，零上限会刻意读取一个字节来判断是否有输入，调用前应明确这是否符合协议。

什么时候应该改用 io.CopyN？

只需要复制精确数量并希望由返回的字节数判断是否完整时，可用 io.CopyN；需要把限制器继续交给多个消费者，或需要先探测超限时，io.LimitReader 更灵活。