Go net/http 怎样设置请求体大小上限

Go HTTP服务可以在读取前将 r.Body 替换成 http.MaxBytesReader(w, r.Body, limit)。读取超过限额时识别 *http.MaxBytesError，由处理器返回413；不要只看Content-Length，也不要认为包上限流读取器就会自动发出错误响应。

设想一个接收文章草稿的JSON接口，原来直接ReadAll，再解码和保存。改造目标是把总输入限制为1 MiB，并且在体积判断结束前不产生业务写入。下面讨论的是接口实现迁移，不是某个新Go版本带来的破坏性变化。

这次改造只改变请求体读取边界

保留POST路由、JSON字段和正常响应，把读取层与业务层分开。上限参数单位是字节；示例的1 MiB是演示约定，不是适合所有接口的默认值。文件上传和小型JSON接口应使用不同额度。

限制必须放在第一个读取Body的组件之前。如果日志中间件已经把原始Body完整读进内存，后面的包装无法追回这笔开销。同样，网关限制可以作为外围保护，但不能替代接口自己明确的输入契约。

旧写法的三种隐患

io.LimitReader达到N字节便表现为EOF。若业务只看到前N字节且没有额外检测，容易把截断误认成完整输入。它不是不能使用，而是拒绝超限时还需要额外的N+1探测和长度判断，不能照搬只读N字节的片段。官方接口说明：https://pkg.go.dev/io#LimitReader。

用完整读取把超限错误接住

小型JSON请求可以先在限额内完整读取，再解码。这个取舍增加了一份原始字节缓冲，却让“完整请求体是否越界”和“JSON是否有效”的错误顺序非常清楚。下面是独立示例代码，不是已执行的运行记录。

package main

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

const maxBodyBytes int64 = 1 

阅读代码时关注三个位置：Body包装在ReadAll前，读取错误立即返回，解析成功后仍有业务字段检查。即使ReadAll返回了部分字节，只要同时存在错误，就不能继续把那部分内容当完整请求执行写入。

官方文档说明，MaxBytesReader用于限制入站请求体，越界读取产生MaxBytesError；关闭它也会关闭底层读取器。它不会替业务处理器选定413响应内容。对应说明：https://pkg.go.dev/net/http#MaxBytesReader。

JSON流式解析为什么还要检查结尾

如果把ReadAll改成直接对包装Body调用json.Decoder，第一次Decode成功只表示取得了一个JSON值。接口若要求整个请求只有一个值，就应继续确认结尾，不能在第一次成功后立即保存。

例如一个很短的合法JSON对象后面跟着大量空白：第一次Decode不一定读到限额之外。这种情况下，没有继续消费就不能证明整个请求体没有超限。可以再次Decode并要求io.EOF，同时把第二次读取中出现的MaxBytesError映射为413；若第二次获得另一个值，则拒绝多值输入。限制是读取时生效，不是凭对象构造瞬间完成所有字节判断。

大文件接口应选择受限流式处理，避免把文件全留在内存。若边读取边写暂存文件，错误时必须清理暂存内容，最终提交留到读取结束以后。请求体限额也不等于解压后数据限额：若服务主动解压，应为解压后的输出另设边界。

把边界场景列进回归用例

以下是建议编写的回归用例及预期判断，没有在本文环境实际运行。可以使用httptest构造请求，重点检查状态码以及异常请求没有触发业务保存。

• 有效JSON且小于上限：示例预期204。
• 恰好N字节的有效JSON：在实际EOF处完成读取，不能把等于上限当超限。
• N+1字节输入：完整读取时预期413。
• 长度未知的请求：应仍受读取器限制，而不是跳过保护。
• 体积合格但JSON格式错误或包含第二个值：预期400。
• 短JSON加超额尾部空白：完整读取方案预期413。
• Body模拟读取故障：预期400且不进入业务写入。

反向代理、客户端和Go处理器可能分别拒绝请求，因此集成回归还要区分响应来源。日志记录错误类别、接口和额度即可，不要把完整上传内容或敏感字段写进错误日志。

迁移时保留这些接口约定

迁移清单可以压缩成四件事：为每个路由明确字节额度；把包装前移到首次读取之前；把超限、格式和业务错误分别处理；将提交动作放在完整输入确认之后。限额只解决体积问题，慢速上传还要有独立的超时策略，并发资源也要单独管理。

设置MaxHeaderBytes能限制Body吗？

不能把请求头额度当请求体额度。需要限制的是读取Body时消耗的字节，两者是独立输入边界。

ParseMultipartForm的maxMemory就是上传总大小吗？

不要把内存阈值当整个请求总额度。上传接口仍应在解析之前设置总请求体限制，并安排临时文件清理。

能不能一套中间件统一所有接口？

可以统一包装和错误格式，但额度应由路由策略提供。小JSON、批量导入和文件上传共享同一个很小额度，会把正常业务也拒绝。