Go HTTP 服务怎么限制请求体：MaxBytesReader、超时与错误日志边界

上传接口刚上线时，最先暴露问题的往往不是业务逻辑，而是一条没有大小边界的 io.ReadAll(r.Body)：正常 JSON 只有几十 KB，异常请求却能把进程的堆顶到告警线。Go 的 net/http 已经提供了入口限长、请求级截止时间和可区分的错误响应，关键是把它们放在正确的位置，并让日志记录“拒绝了什么”而不是把整段请求体打出来。

先在 handler 入口用 http.MaxBytesReader 限住可读字节，再用请求级超时约束读取时间；超限返回明确状态码，日志只保留路径、来源和实际处理结果。

先把生产边界写成一张表

一个订单导入接口通常同时受应用、代理和客户端三层约束。只在 Go 代码里改一个数字，容易出现代理先截断、应用却返回另一种错误的情况。可以先把边界列清楚：

这里用一个只接收 JSON 的 /v1/import 作为例子，上限设为 1 MiB。这个值只是实验室起点；如果接口还要接收图片或压缩包，应拆成单独路由，不能把所有入口都放宽。

在读取之前包住 Request.Body

MaxBytesReader 的位置决定了它能不能真正挡住大请求。下面的 handler 先生成请求标识，再替换 r.Body，之后才调用 JSON 解码。读取动作发生在限制之后，超出 1 MiB 时会得到可判断的读取错误。

const maxImportBody int64 = 1 

示例里的 newRequestID、recordReject 和 writeJSONError 是项目自己的辅助函数，重点在包裹顺序。第二次解码用于拒绝“一个请求里拼接多个 JSON 值”的输入，避免只解出第一段就当成完整请求。写完代码后可以先传一个1.1MiB的测试文本，确认解码时直接抛出超限错误，不会占用多余内存。

不要用错误字符串作为唯一契约

不同 Go 版本或中间封装可能改变错误文本。小项目可以先用字符串判断跑通链路，生产代码更适合在读取层维护一个明确的“超限”标记，或者把 body reader 封装成自己的错误类型。无论采用哪种方式，响应码、错误字段和日志原因要保持一致。

给慢读取留出结束时间

大小限制解决的是“读多少”，不能解决“读多久”。客户端可以每隔很久才发几个字节，让连接长期占用服务资源。入口 server 可以有整体读写超时，单个接口也可以用请求上下文表达更短的业务期限。

server := &http.Server{
    Addr:              ":8080",
    ReadHeaderTimeout: 2 * time.Second,
    ReadTimeout:       8 * time.Second,
    WriteTimeout:      10 * time.Second,
    IdleTimeout:       60 * time.Second,
    Handler:           routes,
}

func withImportDeadline(next http.Handler) http.Handler {
    return http.TimeoutHandler(next, 6*time.Second, `{"error":"request_timeout"}`)
}

ReadHeaderTimeout 主要针对请求头，ReadTimeout 覆盖服务端读取请求头和请求体的时间；TimeoutHandler 更像 handler 层的截止线，不能替代对整个服务端生命周期的设计。文件上传、长轮询和流式响应通常需要单独的参数，不要把这组值复制到所有路由。

这里别急着把时间调到很大。把 1 MiB 请求体允许慢慢读完的时间控制在几秒内，通常比让每个连接等待一分钟更容易估算资源占用。上线前用慢速客户端和正常客户端各跑一遍，观察超时是否真的释放了连接。

把超限、格式错和业务拒绝分开

客户端收到 400、413 或 422 时，下一步动作并不一样：格式错误应该修 JSON，体积超限应该缩小输入，业务校验失败则应该修改字段。统一返回 500 会让调用方误重试，也会把真正的容量问题藏起来。

type ErrorResponse struct {
    Error     string `json:"error"`
    RequestID string `json:"request_id"`
}

func recordReject(id, path, reason string, cost time.Duration) {
    log.Printf("request_rejected request_id=%s path=%s reason=%s cost_ms=%d",
        id, path, reason, cost.Milliseconds())
}

日志里保留 request_id、路径、原因和耗时，已经足够把一次拒绝串到网关和业务日志。不要输出 Authorization、Cookie，也不要把用户提交的 JSON 原文塞进错误日志；大请求恰好是最不适合被复制多份的数据。配置完后可以抽样查几条错误日志，确认没有敏感字段溢出，排查问题所需的关键字段都齐全。

代理层和测试用例要一起验收

应用层通过不代表线上链路已经一致。检查 Nginx 或 API 网关的 body limit、读取超时和错误映射；如果代理层先返回 HTML，而应用层设计的是 JSON，客户端仍然会遇到难以处理的分支。

单元测试至少覆盖四类输入：小于上限的合法 JSON、刚好接近上限的合法 JSON、超过上限的正文、语法正确但字段不合法的 JSON。测试断言状态码和错误字段，不要只断言 handler 没有崩溃。

func TestImportBodyLimit(t *testing.T) {
    small := strings.NewReader(`{"items":[{"id":"a-1"}]}`)
    req := httptest.NewRequest(http.MethodPost, "/v1/import", small)
    req.Header.Set("Content-Type", "application/json")
    rr := httptest.NewRecorder()

    importHandler(rr, req)

    if rr.Code != http.StatusAccepted {
        t.Fatalf("want 202, got %d", rr.Code)
    }
}

再补一条超限测试时，不要只依赖 Content-Length 预判。分块传输、代理重写和客户端实现都可能让这个头部不可靠，真正的读取限制仍应落在 reader 上。

常见问题

MaxBytesReader 能限制文件上传吗？

可以作为总入口限制，但文件上传通常还要给单文件、总表单和磁盘临时目录分别设边界，并检查文件类型与落盘空间。

请求体超限应该返回 400 还是 413？

如果确定原因是请求内容超过服务器愿意接收的大小，413 更能表达真实原因；格式错误和字段校验失败再分别使用 400 或 422。

只设置 Content-Length 检查够不够？

不够。它可以提前拒绝一部分明显超限的请求，但不能替代实际读取时的限制，尤其不能覆盖分块传输和经过代理改写的场景。

把入口防护变成可回归的契约

请求体防护不是单独加一个数字，而是把大小、时间、状态码和日志组成一套能复查的契约。先在 handler 读取前限长，再为慢读取设截止时间，最后让代理、测试和监控使用同一组原因字段。这样遇到异常大请求时，服务知道什么时候拒绝，调用方也知道该缩小输入还是修正内容。