Go io.LimitReader 组合 MaxBytesReader 时先后顺序怎么选

在 Go HTTP 服务里同时使用 http.MaxBytesReader 和 io.LimitReader 时，通常应该先把 Request.Body 交给 MaxBytesReader，再从它上面派生 io.LimitReader。前者守住整个请求的资源边界，后者限制一次业务读取；顺序反过来，外层就可能只看到一个提前结束的普通 Reader，失去请求级超限语义。

先区分两种限制：请求上限和读取上限

io.LimitReader(r, n) 返回一个普通 io.Reader，它最多从 r 暴露 n 个字节，额度用完后表现为 EOF。它适合限制一次解码、一个文件片段或一段协议字段，但它不知道自己是否包在 HTTP 请求里，也不会替你关闭原始 Body。

http.MaxBytesReader(w, r, n) 则是 HTTP 服务端的请求体保护器。它返回 io.ReadCloser，超过额度后会返回 *http.MaxBytesError，并可借助 ResponseWriter 尝试关闭连接。两者不是同一个“限流函数”的别名：

服务端组合时为什么先包 MaxBytesReader

请求进入 Handler 后，先替换 r.Body，再从新的 Body 派生更小的读取窗口，是最清楚的分层方式。这样所有后续读取都经过请求级保护；业务代码只关心自己的局部额度。

func decodePayload(w http.ResponseWriter, r *http.Request) {
	const requestLimit = 8  payloadLimit { // 多出的字节说明业务窗口确实被突破
		http.Error(w, "业务载荷过大", http.StatusRequestEntityTooLarge)
		return
	}
	// data 已经处在请求级和业务级两个边界之内，再交给解码器。
	_ = data
}

顺序反过来时，若先把原始 Body 放进 io.LimitReader，它到额度后只会报告 EOF；随后再套 MaxBytesReader，外层未必能知道原始请求其实还有更多内容，而且 io.NopCloser 之类适配还可能让关闭责任变得模糊。因此 HTTP 请求级包装应尽量靠近原始 Body。

用 limit+1 判断业务数据是否超出上限

如果业务上限是 1 MiB，直接 io.LimitReader(r.Body, 1 后读取，长度等于 1 MiB 时有两种可能：输入刚好结束，也可能还有第 1 MiB 之后的字节。只读到额度本身，无法区分这两个状态。

把窗口扩大一个字节即可：保留前 limit 个字节用于解码，第 limit+1 个字节只用于判定。注意，这个“多读一个字节”是业务边界的判断策略，不是把外层请求上限放宽；外层的 MaxBytesReader 仍然应该先设置。

常见问题

MaxBytesReader 能不能替代所有 LimitReader？

不能。它适合请求体总上限；一个请求内还要拆分多个业务段时，仍需要用 io.LimitReader 或解码器自己的边界。

LimitReader 超限一定会报错吗？

不会。它的设计是到达额度后返回 EOF；如果业务必须识别超限，应使用 limit+1 的读取窗口。

为什么要显式关闭 r.Body？

因为 MaxBytesReader 是 ReadCloser，关闭它能把关闭动作传递给底层请求体。局部的 io.LimitReader 不承担这个资源生命周期。

可以把组合原则记成一句话：先用 MaxBytesReader 保护 HTTP 请求，再用 io.LimitReader 划分业务读取窗口；需要识别局部超限时，再额外读取一个字节。