Go HTTP 服务怎么按请求大小限制 JSON Body

Go HTTP 接口接收 JSON 时，最稳妥的做法是把 r.Body 先交给 http.MaxBytesReader，再让 json.Decoder 读取它。这样限制的是实际读取量，而不是只相信客户端提交的 Content-Length；超出上限时还能通过 *http.MaxBytesError 单独返回 413。小型 JSON 接口通常可以先从 1 MiB 左右的上限开始，再按字段和业务负载调整。

按作用范围选择请求体限制方式

先区分“限制哪一层”。单个路由需要特殊上限时，用 http.MaxBytesReader(w, r.Body, limit) 替换 Body；多个路由共享同一个上限时，可以用 http.MaxBytesHandler 包住 Handler。io.LimitReader 只是通用读取器，不能代替面向 HTTP Body 的关闭行为和超限错误；Content-Length 只适合做提前拒绝的辅助判断，不能当作唯一防线。

在 JSON Decoder 读取前包住 r.Body

限制器应当紧贴 Body 设置，后续所有解码都从这个受限读取器获取数据。下面的例子还打开了未知字段检查：客户端把字段名写错时，接口直接告诉它，而不是静默丢弃。

package api

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

type OrderInput struct {
    SKU   string `json:"sku"`
    Count int    `json:"count"`
}

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

这里的关键不是把数字写成 1 MiB，而是限制器的位置。若先用 io.ReadAll(r.Body) 再判断长度，过大的数据已经进入内存；若先把 Body 交给不受限的解析路径，同样失去了这层保护。DisallowUnknownFields 解决的是字段契约，不是大小限制，两者应当分别理解。

区分超限、语法错误和尾部数据

Decoder.Decode 报错时，不要把所有情况都写成“参数错误”。通过 errors.As 判断 *http.MaxBytesError，可以把真正的大小超限映射为 413；普通 JSON 语法错误、未知字段和第二个 JSON 值则属于请求内容问题，通常返回 400。

第二次 Decode 是一个容易漏掉的检查。第一次成功只说明读到了一个 JSON 值，输入 {"sku":"A"}{"sku":"B"} 仍可能留下第二个值。第二次解码必须得到 io.EOF；得到别的结果，就说明请求后面还有垃圾或格式不完整的数据。

如果接口允许 JSON 后跟空白，第二次解码仍会在读完空白后得到 io.EOF，这正是期望行为。不要用字符串查找大括号，也不要仅凭 r.ContentLength 判断解析是否安全。

用决策表确定上线前的限制策略

上限不是越小越安全。先看请求模型：只有几个字符串和数字的命令接口，可以使用较小限制；包含嵌套数组的批量接口，应按最大合理批次数估算，并把数组长度校验放在解码之后。若同一服务同时有小 JSON 和大批量接口，按路由设置 MaxBytesReader 比给整个服务一个过大的统一值更容易解释。

生产环境还应把网关、反向代理和应用层的限制分别记录清楚：代理可以提前拒绝，但应用层仍需要自己的边界；日志记录请求 ID、路由和错误类别即可，不要把完整 Body 写入日志。这样既能控制内存和解析成本，也能让调用方根据 413 或 400 采取不同修复动作。

常见问题

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

不够。它可以快速挡住明确声明过大的请求，但实际读取仍应经过 MaxBytesReader。

MaxBytesReader 和 MaxBytesHandler 怎么选？

按路由差异选择前者，按整个 Handler 统一策略选择后者。需要多个 JSON 接口不同上限时，不要强行共用一个 Handler 上限。

返回 413 还是 400？

明确识别到读取超过字节上限时返回 413；JSON 格式、字段或尾部内容不符合约定时返回 400。