Go net/http MaxBytesReader 的请求体上限控制

在 Go HTTP 服务中，应当在读取或解析请求体之前，把 r.Body 替换为 http.MaxBytesReader(w, r.Body, limit)。当读取尝试越过预算时，用 errors.As 识别 *http.MaxBytesError，由处理函数明确返回413，并丢弃已读出的部分数据。只检查 Content-Length 无法覆盖长度未知的请求。

官方地址：https://pkg.go.dev/net/http#MaxBytesReader

面对一个接收短消息的接口，我更倾向于先明确“最多接收多少字节”，再考虑 JSON 字段。下面采用64 KiB作为示例预算；这是设计取舍，不代表所有接口都应使用这个数值，也不是实际压测结论。

先把请求体预算写成明确的字节数

64 表示65536字节。这里限制的是包装读取器所见的数据量，不是字符数，也不等于解析后对象的堆内存大小。中文字符串的字符数量和UTF-8字节数不能直接互换。

小型 JSON 接口可以先限量读完再解析；大文件上传则应使用流式处理和临时存储方案，同时仍然约束总量。不能把所有上传接口统一改成大容量 io.ReadAll。

在任何读取动作之前替换 Body

中间件、日志组件或表单解析器只要提前读取过原始 Body，后面新增的包装器就无法追溯限制那些已消耗的字节。我的安排是让容量限制位于所有正文消费者之前，并要求下游只使用替换后的 r.Body。

MaxBytesReader 返回 io.ReadCloser，调用它的 Close 会关闭底层读取器。它只安装读取约束，不会在创建时主动把请求读完，也不会自动替你写出413响应。

用错误类型区分超限，再决定响应

下面是可接入现有服务的处理函数。示例使用完整读取，是为了让容量错误在解析与业务操作之前被发现。代码没有在本文环境中执行，响应含义由代码分支说明。

package ingest

import (
    "encoding/json"
    "errors"
    "io"
    "log"
    "net/http"
)

const maxBodyBytes int64 = 64 

errors.As(err, &tooLarge) 能识别错误链中的超限类型，避免按错误字符串判断。普通读取错误归为400只是这个接口的策略；更复杂的服务可以对取消、超时和连接中断细分记录。客户端已经断开时，写出的错误响应也未必能送达。

重要的是错误分支立即返回。io.ReadAll 可以同时返回部分数据和错误，不能因为拿到了部分 JSON 或部分记录就继续执行写库。限制读取量和避免业务半提交，需要这两层约束共同成立。

读满预算并不等于已经发现超限

恰好有N字节并正常结束的请求可以被接受。只有读取进一步发现预算之外还有数据，才会得到超限错误。因此，消费者如果只读取前几个字段就停止，可能没有触及超限位置，不能据此证明整个请求体小于上限。

本文通过受限的 io.ReadAll 读取到结束来解决这个问题。若改用 json.Decoder，一次 Decode 成功只说明解析到一个值；尾部空白、后续JSON值和剩余数据必须另有明确处理策略。不要把一次解码成功直接当作全文容量通过。

官方实现可能为判断是否越界额外读取一个字节，但不会把超出预算的内容交给消费者；不要把N解释成网卡、代理或连接层绝不会接触更多字节的保证。

把日志和回归场景放在同一份接口约定里

我会记录路由标识、拒绝原因和配置预算，不记录被拒绝的请求正文。长度声明可以用于提前拒绝已知过大的请求，但长度未知时仍然必须保留读取器限制。外层代理的限制也应与应用策略协调，避免读者误以为每次413都来自这一段Go代码。

这些是建议在项目中覆盖的回归场景，不是本文已运行的测试报告。字节上限也不负责限制读取耗时、并发请求数、解压后的膨胀体积和业务对象数量；有这些需求时，应把时间、并发和解压边界另行设计。尤其在应用自己解压正文时，压缩数据与解压数据需要各自明确预算。

相关问题

能用 io.LimitReader 替换吗？

它能限制交给消费者的数据，但到达限制后表现为EOF，不能直接区分原文恰好结束还是仍有更多内容。请求体拒绝策略需要明确超限错误时，MaxBytesReader更容易表达意图。

上限设为0会禁用限制吗？

不会。0表示只允许空正文；官方实现将负数也按0处理。配置读取失败时应明确报错，不能用负数表达“无限制”。

为什么已经包装仍返回200？

常见原因是没有读取到超限位置、提前写出成功状态，或者忽略了读取错误。把响应提交放到完整读取、解析和业务条件通过之后，并明确处理错误分支。

对短消息接口，我选择受限读取再解析，是为了让拒绝条件和业务提交位置一眼可见；如果请求规模较大或需要流式消费，就应调整存储和提交方式，同时保留同样清楚的容量错误语义。

参考：Go HTTP请求体限制文档；Go请求体读取器实现。