Go io.LimitReader 读满上限后如何区分截断

io.LimitReader 适合给流设置“最多读取多少字节”的边界，但它不会告诉你“这个边界是因为输入真的结束，还是因为限制器主动截断”。因此，直接读取 limit 字节后看到 io.EOF，不能证明内容没有超长。

要区分截断，探测窗口应设置为 limit+1：读到第 limit+1 个字节就判定输入超过上限；最多读到 limit 个字节并自然结束，才表示输入没有超过限制。

• LimitReader 是“上限控制器”，不是“超长检测器”。
• 截断判断依靠多读一个字节，而不是依靠 EOF。
• 底层非 EOF 错误必须原样返回，不能被 truncated 结果掩盖。

为什么读到 EOF 仍然无法判断

io.LimitReader(r, limit) 返回的 Reader 最多向调用方提供 limit 字节。官方文档说明，达到这个数量后它会停止并返回 EOF；如果底层输入本来就只有这么长，最终也会出现 EOF。两个场景的外部表现相同：

用 limit+1 建立截断判断

下面的封装把“保留内容”和“是否超长”分开返回。使用 io.ReadAll 只是为了让示例集中说明边界；面对大文件时，应改成分块读取并在超过上限时立即停止。

package main

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

// readAtMost 读取最多 limit 字节，并通过额外一个字节识别是否超长。
func readAtMost(r io.Reader, limit int64) (data []byte, truncated bool, err error) {
    if limit  limit {
        return probe[:limit], true, nil // 第 limit+1 个字节证明输入确实超长。
    }
    return probe, false, nil // 未读到额外字节，输入没有超过上限。
}

func main() {
    data, truncated, err := readAtMost(strings.NewReader("abcdef"), 5)
    if err != nil {
        panic(err)
    }
    fmt.Printf("%q truncated=%v\n", data, truncated) // 输出 "abcde" truncated=true。
}

这里的关键不是 io.EOF，而是返回数据长度：len(probe) == limit+1 表示探测窗口被填满，说明至少还有一个字节超出业务上限。返回给调用方的内容仍只保留前 limit 字节。

错误、空输入和大上限要分开处理

io.ReadAll 会把正常的 EOF 视为读取结束，但其他错误会返回给调用方。网络流可能在达到上限前返回超时、连接中断或自定义错误，这些情况不应被标成“截断成功”。如果业务需要区分“空输入”，再额外判断 len(data) == 0，不要把它和截断混为一谈。

还要留意 limit+1 的整数溢出，所以示例拒绝 math.MaxInt64。如果限制来自 HTTP 头、配置文件或用户输入，先解析并校验非负范围；不要让异常的大数绕过内存预算。

把返回值设计成调用方能用的结果

上传接口、消息消费和文本预览通常不只需要一段字节，还需要知道“是否应拒绝”“是否可重试”。可以沿用上面的三值结果：err != nil 优先处理底层失败；truncated 为真时返回明确的超长错误；其余情况才进入解析或保存。

data, truncated, err := readAtMost(body, 1

速记规则是：限制读取用 LimitReader(r, limit)；检测是否超限用 LimitReader(r, limit+1)；读取结果先看错误，再看是否读到额外字节；需要严格区分边界时，永远不要仅凭 EOF 下结论。

常见疑问

能不能读取完后检查 LimitedReader.N？

可以观察具体的 *io.LimitedReader，但它只反映限制器剩余配额，不能说明底层 Reader 是否还有数据；要判断超长，仍应采用多读一个字节的探测策略。

为什么不直接用 io.ReadFull？

io.ReadFull 适合要求至少填满固定缓冲区的场景，而这里要保留不超过上限的数据并识别额外输入。limit+1 窗口更直接地表达了这个业务边界。