Go JSON 请求体过大怎么拦：MaxBytesReader、413 和连接复查

批量导入接口突然蹦出内存尖峰，日志里却只飘着一条普通的 invalid character。这类问题很容易被误当成 JSON 格式错误处理：调用 json.Decoder，解析失败就直接返回 400。真正有风险的是，请求体在解析逻辑执行前就已经被网络层持续读进进程内存，格式报错不等于请求体积被控制住了。

内存尖峰是怎么被大 JSON 推出来的

出问题的现场接口是 POST /admin/import，正常情况下传的文件只有几百 KB，结果调用方直接把整批历史记录编码成了单个 JSON 数组塞了进来。服务端原先的写法是这样：

func importHandler(w http.ResponseWriter, r *http.Request) {
    var req ImportRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "bad json", http.StatusBadRequest)
        return
    }
    save(req.Items)
    w.WriteHeader(http.StatusNoContent)
}

这段代码可以识别出格式损坏的坏 JSON，但没有回答一个更前置的问题：单次请求最多允许读多少字节？如果请求体里塞了几十 MB 的字符串，解码器为了完成解析会不停往内存里读；要是结构里还嵌套了大数组或者超长字段，内存占用的上涨速度还会更快。

时间线里最容易漏掉的三个检查点

把单次请求的处理流程按时间线拆开，根因一眼就能看明白。

1. 网关放行请求，服务端收到 Content-Length 数值很大的 body；如果用的是分块传输模式，甚至不能完全信任这个字段的数值。
2. handler 直接把 r.Body 传给解码器，全量读取的动作发生在所有业务校验逻辑之前。
3. 解析失败后只返回 400 错误，监控系统把“大请求超限”和“坏 JSON 格式错误”混在一起统计，直接带偏后续的排查方向。

这里别急着把限制逻辑直接写成“看到 Content-Length 太大就直接拒绝”。这个判断可以做快速拦截用，但真正的读取上限一定要放在 body 包装层，才能覆盖没有可靠长度声明的异常请求。

触发条件：解码器负责校验格式，不负责业务层面的体积上限

JSON 解码器只懂语法规则和目标结构定义，完全不知道“批量导入接口最多接受 2 MiB 数据”这个业务约定。把格式校验和体积校验混在一起处理，很容易出现两种不合理的结果：

做这个区分很有必要。413 是告诉调用方“请求整体太大，缩小体积后再来提交”；400 是告诉调用方“提交的内容本身不符合接口约定”。客户端拿到不同的状态码，才能执行对应的处理逻辑。

修复 handler：先封顶，再解码，再核对尾部

下面我们把体积上限设置为 2 MiB。http.MaxBytesReader 超过限制后会让后续的读取动作直接返回错误，避免 handler 无边界地消费请求 body 数据。

const maxImportBody = 2  5000 {
        http.Error(w, "too many items", http.StatusBadRequest)
        return
    }
    save(req.Items)
    w.WriteHeader(http.StatusNoContent)
}

实际项目里，超限错误的匹配方式要结合你用的 Go 版本和测试结果来确认，不要只靠错误字符串包含的内容判断。更稳妥的做法是专门给超大请求场景写测试用例，确认响应码、日志字段和实际读取行为都符合预期；如果中间件层已经统一做了错误转换，也可以在中间层保留一个明确的“body_limit”标记。

上线前用三组请求把边界钉住

不要只发一个正常样例测试就完事。至少准备下面三组请求，核对状态码、日志输出和内存曲线。

# 正常 JSON：预期 204
curl -i -H 'Content-Type: application/json' \
  --data '{"items":[{"id":1,"name":"demo"}]}' \
  http://127.0.0.1:8080/admin/import

# 合法 JSON 但条目过多：预期 400
# 超过 2 MiB 的 body：预期 413

• 正常请求：确认数据保存动作只执行一次，响应返回 204。
• 结构合法但条目超量：确认没有写入部分数据，响应返回 400。
• 总字节数超过预设上限：确认响应返回 413，日志包含 reason=body_limit，进程内存不会随 body 体积线性上涨。

如果服务前面还挂着 Nginx、Ingress 或者 API 网关，最好把边缘层的限制值设得略高于应用层的上限，让应用仍然能输出统一格式的日志；要是边缘层会直接截断超限请求，也要在监控里区分开“入口层直接拒绝”和“应用层主动拒绝”两类指标。

常见问题

只检查 Content-Length 能不能解决问题？

不能。它适合用来快速拒绝明显过大的请求，但碰到分块传输或者缺失长度声明的请求场景，还是需要 MaxBytesReader 来保护实际的读取动作。

为什么超过上限不一定都返回同一个错误文本？

错误会经过读取器和解码器多层包装，具体的文本内容可能随读取位置变化。接口契约里要固定对外返回的状态码和提示消息，再在测试用例里覆盖几种不同的读取路径。

设置 2 MiB 是不是通用答案？

不是。你要根据业务字段长度、批量提交条数和网关限制综合估算，再用真实的请求分布数据校准。导入类接口的上限可以比普通 JSON 查询接口大，但不要无限制放开。

返回 413 后还要关闭请求体吗？

要。不管是正常解析、格式错误还是请求超限的场景，都要在 handler 入口处安排好请求体关闭的逻辑，不要把连接和资源回收的动作完全依赖客户端行为触发。

把这次修复变成长期门禁

最后留下来的不是某个固定的数字配置，而是一套可复查的校验边界：读取层有明确上限，状态码能区分不同错误原因，业务条数有单独的校验规则，监控能统计到拒绝量和 body 大小分布。下次再碰到内存尖峰异常的时候，先看 reason=body_limit、请求路由和近五分钟的拒绝比例，再决定是调整网关参数还是修改应用层的体积限制。