Go io.LimitReader 包装请求体后为什么拿不到完整错误信息

把 HTTP 请求体交给 io.LimitReader 后，读到上限却只得到 EOF，通常不是错误丢了，而是限制器主动结束了读取。它只承诺“最多读取 N 个字节”；当 N 归零时直接返回 EOF，不会继续向底层 Reader 询问后面的内容。因此，用它包住请求体时，不能把 io.ReadAll 返回 nil 理解成“原始请求体已经完整且没有问题”。

官方地址：https://pkg.go.dev/io#LimitReader

先看清 io.LimitReader 的 EOF 边界

io.LimitReader 返回的实际实现是 *io.LimitedReader，它维护一个公开的剩余字节数 N。每次成功读取后，N 都会减少；当 N 时，下一次读取直接返回 0, io.EOF。这个 EOF 是限制器的边界信号，不等同于底层请求体已经自然结束。

例如请求体有 1200 字节，限制值是 1000。读取前 1000 字节后，限制器已经没有额度；即使底层 Reader 在第 1001 字节附近才会返回一个网络错误，限制器也不会再调用它。此时 io.ReadAll 看到的是限制器给出的正常 EOF。

区分正常结束与底层读取错误

先把几个结果放在一起看，排查时就不会只盯着 err：

还有一个容易混淆的点：io.ReadAll 的职责是读到 EOF，它会把正常 EOF 转换为 nil。所以“data 有内容且 err == nil”只能说明这次读取完成，不能说明被包装的原始 Reader 还有没有未观察到的字节。

用 max+1 检测请求体是否超限

如果目标是限制请求体大小，常见做法不是把限制值直接设为 maxBody，而是允许限制器多读一个字节。这样，长度等于 maxBody 表示没有发现超限证据，长度大于它则可以明确拒绝：

import (
    "fmt"
    "io"
)

const maxBody = 1  maxBody {
        // 不把超限数据交给 JSON 或表单解析器，避免无谓占用内存。
        return nil, fmt.Errorf("请求体超过 %d 字节", maxBody)
    }
    return data, nil
}

这里的关键不是“多读一点就更完整”，而是多出的一个字节提供了可判断的证据。若底层数据在 maxBody+1 之前就报错，io.ReadAll 仍会把错误传回来；若数据达到额外字节，长度检查会在业务解析之前拦截它。

按读取结果设计错误处理

生产代码可以把判断顺序固定为三项：先看读取错误，再看长度是否超过上限，最后才交给 JSON、XML 或表单解析器。不要用 errors.Is(err, io.EOF) 去猜请求体是不是完整，因为限制器产生的 EOF 可能只是配额用完；也不要把原始错误替换成一句“请求体为空”，否则网络中断、客户端提前关闭等原因会被抹平。

• 需要硬性拒绝超限：使用 maxBody+1，并在解析前检查长度。
• 需要保留诊断信息：用 %w 包装底层错误，同时避免记录完整请求体。
• 协议要求固定长度：额外比较声明长度与实际读取长度，不把 EOF 自动当成成功。
• 读取后还要解析：把“读取成功”和“内容格式合法”分成两个错误阶段。

相关问题

为什么直接用 io.LimitReader(r, maxBody) 检测超限不可靠？

因为读到第 maxBody 个字节后，限制器可能直接返回 EOF；它没有机会告诉你底层是否还存在第 maxBody+1 个字节。

读到 EOF 就一定是请求体完整吗？

不一定。EOF 可能来自原始 Reader，也可能来自 LimitedReader.N 归零。要判断大小，应该保留一个额外字节作为证据。

为什么不能只检查 len(data) == maxBody？

因为刚好等于上限的请求和超过上限但被截断到上限的请求，在这一次读取中看起来完全一样；maxBody+1 才能把两者分开。