Go 服务端怎样限制请求体大小并返回明确错误

我在接收 JSON、表单或小文件的 Go 接口里，最先会把请求体上限放到读取入口，而不是等业务对象已经读进内存后再判断。标准库的 http.MaxBytesReader 专门用于限制服务端传入的请求体；当读取超过上限时，它会返回 *http.MaxBytesError。因此比较稳妥的组合是：先替换 r.Body，再读取；用错误类型识别超限；最后返回 413 Request Entity Too Large，不要继续处理半截数据。

官方资料：https://pkg.go.dev/net/http#MaxBytesReader、https://pkg.go.dev/net/http#MaxBytesHandler

先把请求体上限放在读取入口

Content-Length 可以帮助服务端提前拒绝一个明显过大的请求，但它不是最终边界：请求可能使用分块传输，也可能没有可直接信任的长度字段。真正开始读取 Request.Body 时，仍需要一个会在超限位置返回明确错误的 Reader。

http.MaxBytesReader(w, r.Body, limit) 返回一个 io.ReadCloser。它和 io.LimitReader 的用途相近，但更适合服务端请求体：超出上限时返回 *http.MaxBytesError，并且关闭包装器时会关闭底层 Reader。上限应该按业务正文而不是按“整个 HTTP 请求”估算，例如 JSON 导入、头像上传和批量表单应分别配置。

用受限 Reader 包住 JSON 解码

最重要的动作必须发生在 json.Decoder 或 io.ReadAll 之前。下面的处理器把正文上限设为 1 MiB，并把不同读取错误分成超限、格式错误和其他读取失败。示例是原创说明代码，重点是资源边界和错误类型，不依赖任何第三方框架。

package upload

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

type payload struct {
    Name string `json:"name"`
}

func createHandler(w http.ResponseWriter, r *http.Request) {
    const maxBody = 1 

这里的顺序很关键：如果先用 io.ReadAll(r.Body) 再检查长度，内存压力已经发生；如果只依赖错误字符串，后续维护时很容易把“超限”误判成普通 400。通过 errors.As 识别 *http.MaxBytesError，可以把“格式不对”和“超过配额”交给不同的响应策略。

识别超限错误并返回 413

超限不等于 JSON 语法错误。客户端可以修正正文大小，所以服务端应返回专门表达请求实体过大的 413，而不是笼统地返回 500。响应正文保持简短即可，避免在错误路径里再次回显请求内容。

还要注意，解码器可能在读取过程中提前遇到语法错误；只有实际继续读取到限制位置，才会得到 *http.MaxBytesError。这也是为什么不能只看请求头的 Content-Length 来决定错误类型：它只能做早期判断，最终结果仍以受限读取返回的错误为准。

Content-Length 适合提前拒绝，但不能替代最终保护

对于明确声明长度的请求，可以在读取前做一次廉价判断，让明显超限的上传更早结束：

func bodyTooLarge(w http.ResponseWriter, r *http.Request, limit int64) bool {
    // ContentLength 为负数表示长度未知，不能把未知当成零字节。
    if r.ContentLength > limit {
        http.Error(w, "请求体超过允许大小", http.StatusRequestEntityTooLarge)
        return true
    }
    // 即使长度未知，后续仍必须使用 MaxBytesReader 保护真实读取。
    return false
}

这段判断只能减少一部分无效读取，不能覆盖分块请求、代理重写长度或客户端没有发送长度的场景。生产处理器仍要在真正消费正文前安装 MaxBytesReader。如果读取的是 multipart 表单，也要同时为表单解析过程设定符合业务的内存和文件策略，不能把一个小的单字段上限误当成完整上传治理。

局部包装和 MaxBytesHandler 怎么选

如果只有一个路由需要特殊上限，直接在该处理器里包装 r.Body 最直观：它能和 JSON、表单或文件解析代码放在一起，也便于按请求类型选择不同额度。若一组 Handler 都使用同一个请求体上限，可以用 http.MaxBytesHandler 做外层包装；官方文档说明它会让被包装的处理器使用由 MaxBytesReader 包装后的 Request.Body。

func routes() http.Handler {
    mux := http.NewServeMux()
    mux.HandleFunc("/api/profile", createHandler)

    // 统一限制这一组接口的请求体，业务 Handler 仍负责识别读取错误。
    return http.MaxBytesHandler(mux, 1

外层包装的优点是策略集中，代价是所有路由共享同一个上限；图片上传、批量导入和普通 JSON 往往不应共用额度。需要不同限制时，优先保持路由边界清楚，不要为了少写一行代码而让所有 Handler 接受最大的那档请求体。

采用前记住这四个边界

• 限制要早：先包装 r.Body，再交给 Decoder、ReadAll 或表单解析器。
• 错误要分型：用 errors.As 判断 *http.MaxBytesError，不要把所有读取错误都返回 413。
• 413 不是万能答案：格式错误仍是 400，业务校验失败也应使用对应的业务状态。
• 上限要按路由：普通 JSON、文件上传和批量数据的额度不同，必要时使用多个外层 Handler。

一句话总结：Content-Length 负责尽早发现，MaxBytesReader 负责最终兜底，MaxBytesError 负责把超限变成可判断的类型，413 负责把结果说清楚。

相关问题

http.MaxBytesReader 和 io.LimitReader 有什么区别？

两者都能限制读取量，但 MaxBytesReader 面向服务端请求体，返回 ReadCloser，在超限读取时给出 *http.MaxBytesError，并负责关闭底层 Reader；io.LimitReader 只是通用的读取上限包装。

只检查 Content-Length 可以吗？

不够。长度可能未知，或者请求采用分块传输。Content-Length 可以做提前拒绝，但最终消费正文时仍应使用 MaxBytesReader。

超过上限后还要继续解析吗？

不应该。返回 413 并结束当前处理，避免把半截 JSON、半个文件或不完整表单继续交给业务层。

官方资料（复制地址查看）：https://pkg.go.dev/net/http#MaxBytesReader；批量 Handler 包装说明：https://pkg.go.dev/net/http#MaxBytesHandler；Go 文档入口：https://go.dev/doc/。