Go MaxBytesReader 超限后为什么还需要处理连接状态

http.MaxBytesReader 不只是“读到 N 字节就停”。当读取动作真正越过限制时，它会返回 *http.MaxBytesError，并尽可能通知 Go HTTP 服务器不要复用这条连接。原因是超限请求体可能还有大量字节留在连接中；如果只返回 413 却忽略连接状态，下一次 keep-alive 请求就可能面对未处理完的输入。

官方文档：https://pkg.go.dev/net/http#MaxBytesReader

先建立一个可复现的 1 MiB 边界

假设 JSON 接口允许的请求体上限是 1 MiB，也就是 1,048,576 字节。测试至少准备三组输入：小于上限、正好到上限、比上限多 1 字节；再补一组没有可信 Content-Length 的分块请求。这样可以区分“头部声明过大”和“读取时才发现超限”。

这里不把吞吐量写成一个固定数字，因为网络栈、HTTP 版本和中间件都会改变结果。真正稳定的判断是：超限请求是否被归类为 413、是否出现 *http.MaxBytesError、这条连接后续是否仍被复用。

超限错误不只是一个 413

官方文档说明，MaxBytesReader 与 io.LimitReader 不同：它返回 io.ReadCloser，关闭时会关闭底层读取器，并在越界读取时返回 *http.MaxBytesError。当前 Go 源码会把一次读取缩短到“剩余字节数 + 1”，多读的那 1 个字节用于确认请求体确实超过限制。

同一段源码还会在可能时通知 ResponseWriter 请求过大。标准服务器收到这个信号后，会标记响应结束后关闭连接；若响应头还没写，还会设置 HTTP/1.x 的 Connection: close。所以连接处理是限制器语义的一部分，不是业务层随意追加的优化。

业务代码要把超限和 JSON 错误分开

下面的 Handler 把整个请求体限制为 1 MiB，要求正文只有一个 JSON 值。第二次 Decode 很重要：如果第一个 JSON 对象后面还跟着大量空白或另一个值，只有继续读到 EOF，限制器才有机会发现总大小超限。

package api

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

const maxBody = int64(1 

不建议只看 Content-Length 后直接返回。客户端可以使用分块传输，头部值也不一定可信；而且仅检查声明长度不会触发 MaxBytesReader 的越界路径。可以把 Content-Length 当作提前拒绝信号，但最终仍要对实际读取的 Body 设置硬限制，并明确处理连接。

中间件顺序决定关闭信号能否到达服务器

连接关闭通知依赖标准服务器的内部 ResponseWriter 能力。当前实现通过一个包内接口调用该能力；第三方包装器无法实现这个未导出的接口，MaxBytesReader 也不会自动沿 Unwrap 向内查找。因此，如果日志或指标中间件先把 ResponseWriter 包起来，再创建限制器，业务仍可能收到 MaxBytesError 和返回 413，但服务器侧的关闭提示可能到不了原始写入器。

更稳妥的顺序是让请求体限制器处在外层，先拿到原始 ResponseWriter；随后再进入会包装响应的指标中间件。也可以直接把 http.MaxBytesHandler 放在最外层。

func limitBody(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// 此处应尽量拿到 net/http 传入的原始 ResponseWriter。
		r.Body = http.MaxBytesReader(w, r.Body, maxBody)
		next.ServeHTTP(w, r)
	})
}

func buildHandler(app http.Handler) http.Handler {
	// 正确顺序：限制器最外层，指标包装器位于其内层。
	return limitBody(metricsMiddleware(app))
}

用三类指标验收，而不是只看返回码

第一类是业务指标：200/204、400 和 413 的数量要能分开。第二类是错误指标：记录 *http.MaxBytesError 的次数与 Limit，不要通过匹配错误文本来判断。第三类是连接指标：通过 http.Server.ConnState 统计 StateNew、StateActive 和 StateClosed，再比较正常请求与超限请求后的新建连接数。

复测时，用同一个客户端连续发送“正常 → 超限 → 正常”三次请求。正常路径应保持可复用；超限后下一次请求可能建立新连接。HTTP/2 以流为单位处理，不能用 HTTP/1.1 的 Connection: close 头作唯一依据，因此最终判断要结合实际协议和服务器连接状态。

边界条件和取舍

• MaxBytesReader 不是上传配额系统：它限制单个请求体，不替代用户级限流、磁盘配额或反向代理限制。
• 返回 413 后要立即结束 Handler：http.Error 不会自动阻止后续写入，调用方必须 return。
• 不要主动排空任意大的超限正文：为复用连接而无限读取，会抵消防止资源浪费的初衷。
• 代理限制要对齐：网关上限可以更小，但应用仍应保留自己的限制，防止绕过代理或内部直连。
• 包装器要做回归测试：如果调整中间件顺序后 413 数量不变，但新建连接数变化明显，应优先检查原始 ResponseWriter 是否被隐藏。

相关问题

MaxBytesReader 超限后一定会关闭连接吗？

官方表述是“如果可能”通知 ResponseWriter。标准服务器的原始写入器支持该路径，但自定义包装器可能隐藏它，HTTP/2 的处理也不等同于 HTTP/1.1 连接头。

为什么不能只用 io.LimitReader？

io.LimitReader 到达限制后表现为 EOF，无法直接区分“正好结束”和“还有更多数据”，也不会返回 *http.MaxBytesError 或通知服务器处理连接。

MaxBytesHandler 和 MaxBytesReader 怎么选？

整个路由使用同一上限时，最外层 MaxBytesHandler 更简洁；不同接口需要不同上限或自定义错误响应时，在具体 Handler 中使用 MaxBytesReader 更灵活。