请求大小限制是API服务里一个容易被忽视的细节。一旦有人上传一个几百兆甚至几个G的请求体，服务器内存可能瞬间被打爆，连接被占满，其他正常请求全部排队超时。所以给API加上请求大小限制中间件几乎是标配做法。但这个中间件本身如果实现得不合理，比如先把整个请求体读进内存再判断大小，反而会把防护变成新的负担。这篇文章就来聊聊请求大小限制中间件的常见坑，以及对应的性能优化策略。
请求大小限制的底层机制与常见误区
要理解怎么优化，先得明白请求大小在HTTP层面是怎么表达的。客户端声明请求体大小主要靠Content-Length头，服务端读取这个值就能提前判断是否超限，根本不用碰请求体本身。但如果客户端使用了分块传输编码（Transfer-Encoding: chunked），就没有Content-Length可读，只能边读边计数，读够了限制值就立刻掐断连接。
这里就出现了第一个常见误区：不少中间件为了判断大小，把请求体完整读进内存，读完再交给下游处理器。这种写法在小请求场景下看不出问题，可一旦攻击者故意发送不带Content-Length的超大分块请求，中间件就会老老实实把所有数据缓冲下来，内存直接被吃光。正确的思路是利用HTTP框架本身的能力，比如Express的json({limit: '1mb'})、Koa的koa-bodyparser的limit参数，它们内部都是流式处理，边读边统计，超限立即抛出413错误。
第二个误区是判断时机太晚。有些开发者习惯把校验逻辑写在业务控制器里，等中间件链全部走完、日志记录、鉴权等开销都付出了，才发现请求超限要拒绝。这等于白做了一堆无用功。大小校验应该放在中间件链的最前面，越早拒绝越省资源，甚至在TLS握手完成后的第一个字节读取前就应该完成判断。
流式校验与提前拒绝的实现方案
优化请求大小限制的核心原则只有两条：能不读就不读，必须读就边读边断。下面用一个Node.js的中间件示例来说明流式校验的写法：
function sizeLimit(maxBytes) {
return function(req, res, next) {
// 第一步：优先读Content-Length，零成本判断
const len = parseInt(req.headers['content-length'], 10);
if (!isNaN(len) && len > maxBytes) {
return res.status(413).json({ error: '请求体过大' });
}
// 第二步：分块传输时流式计数
let received = 0;
req.on('data', function(chunk) {
received += chunk.length;
if (received > maxBytes) {
req.destroy(); // 立即断开连接，停止接收
res.status(413).end();
}
});
req.on('end', next);
};
}这段代码的关键点在于req.destroy()的调用。如果只是返回413而不销毁连接，客户端还会继续发送剩余数据，服务端的网卡和带宽照样被消耗，这属于典型的半吊子防护。断开连接能立刻止损，让客户端明白该收手了。
另一个值得注意的点是零拷贝传递。有些自定义中间件读完请求体后，把数据拼成字符串再塞回req.body，这中间多了一次内存分配和复制。更好的方式是把原始流对象直接透传给下游的解析器，让body解析器自己去消费流，中间件只负责监督计数，不碰数据本身。这样中间件的额外开销几乎只剩下一个计数器，可以忽略不计。
不同框架下的配置对比与选型建议
主流Web框架基本都内置了请求体大小限制能力，没必要重复造轮子。下面这张表对比了几个常见框架的配置方式：
| 框架 | 配置方式 | 默认限制 |
|---|---|---|
| Express | express.json({ limit: '2mb' }) | 100kb |
| Koa | koa-bodyparser({ formLimit: '1mb' }) | 56kb（表单） |
| Spring Boot | spring.servlet.multipart.max-request-size | 10MB |
| Go net/http | http.MaxBytesReader(w, r.Body, limit) | 无默认限制 |
从表中可以看出，Go的标准库没有默认限制，这意味着用Go写服务时必须自己显式设置，否则就是裸奔状态。而Express和Koa的默认值偏小，反过来要注意别让正常业务请求被误杀，比如上传头像的接口和普通JSON接口应该配置不同的限制值。
针对不同接口设置差异化限制，推荐用路由级别的中间件而不是全局一刀切。全局限制取所有接口的最大值，等于防护形同虚设；取最小值又会误伤大请求接口。按路由挂载不同的limit参数，既精确又安全。同时别忘了在网关层（如Nginx的client_max_body_size）也配置同样的限制，形成双重防护，让恶意大请求在到达应用之前就被拦截掉，节省应用服务器的资源。
压测验证与监控指标建设
优化做完不能只靠感觉，得用数据说话。压测时重点观察三个指标：一是内存峰值，用超大请求体轰炸服务，观察进程内存是否稳定在限制值附近，如果跟着请求体大小线性增长，说明缓冲逻辑有问题；二是连接复用率，正确实现下被拒绝的连接会快速释放，不会占用连接池；三是P99延迟，正常小请求的延迟不应该因为大请求被拒绝而出现明显波动。
监控层面建议对413状态码单独打点统计，按接口维度聚合。某个接口的413比例突然飙升，通常意味着两种情况：要么有恶意攻击正在进行，要么业务需求变了、原有限制值已经不够用。无论哪种，都需要及时介入处理。同时记录被拒绝请求的Content-Length分布，能帮你判断合理的限制阈值应该设在哪里。
最后提一个容易被忽略的细节：超限响应的返回内容要尽量精简。有些框架默认的413错误页带完整的HTML和调试信息，不仅浪费带宽，还可能泄露服务端实现细节。返回一个简短的JSON错误对象就够了，既节省资源，也符合API的统一错误格式规范。
总结一下，请求大小限制中间件的优化思路可以归纳为：优先信任Content-Length做零成本预判，分块请求用流式计数加及时断连，中间件只监督不搬运数据，按路由精细化配置，再配合网关层防护和完善的监控。做到这几点，这个小小的中间件就能在几乎零开销的前提下，为整个API服务撑起一道可靠的防线。