Nginx基础教程（101）Nginx HTTP机制之处理请求体：别让请求体成“赘肉”！Nginx后厨如何高效处理HTTP“硬菜”？

第一章 订单来了！HTTP请求不只是“报菜名”

想象一下这个场景：你走进一家网红餐厅，服务员递来菜单——这就像HTTP请求的请求头，告诉服务器“我要点菜啦！”。但真正的重头戏在后面：你掏出一张写满三页纸的特殊要求：“牛排要三分熟但表面焦脆，配菜土豆泥要混入黑松露，酱汁单独分装，还要用生肖形状的萝卜雕花……” 这份堪比论文的“附加要求”，就是HTTP请求体。

在Web开发的世界里，GET请求像是喊一句“来碗牛肉面！”那么简单，而POST、PUT这些带着请求体的方法，才是真正的技术活。你上传的每张自拍、填写的每个万字长帖、提交的每个Excel报表，都在请求体里挤着。如果服务器是个脾气暴躁的厨师，看到这么啰嗦的订单可能直接把锅铲一扔：“爱吃不吃！”

好在Nginx是个见过世面的“五星级后厨总管”。今天我们就扒开后厨门帘，看看这位总管怎么用一套行云流水的组合拳，把各种稀奇古怪的“客户需求”安排得明明白白。

第二章 后厨接收区：请求体怎么“卸货”？

当HTTP请求带着请求体浩浩荡荡到达Nginx门口时，第一道关卡就是接收缓冲区。这里有个关键参数：

client_body_buffer_size 128k;

这相当于后厨门口的“临时放菜台”。如果客人点的菜（请求体）小于128KB，直接放台子上处理，速度快得很。但如果客人拉来一卡车食材（比如上传2GB电影），台子显然放不下。

这时Nginx会启动应急方案：把超出的部分暂存到磁盘：

client_body_temp_path /var/nginx/client_temp;
client_body_in_file_only on;  # 调试时可开启，强制所有请求体存文件

想象一下：客人在门口念订单，服务员飞速记在小本子（内存）上，发现订单太长，赶紧掏出台笔记本电脑（磁盘）继续记录。这个“换设备”的过程对用户是透明的，但开发者得知道——如果磁盘IO跟不上，这里就会卡成狗。

幽默插播：我曾见过有人把client_body_buffer_size设为10M，觉得“越大越好”。结果内存疯狂被占，就像给每个顾客都配了个能放一头猪的托盘，结果90%的托盘只放了颗花生米。典型的人傻钱多配置法。

第三章 后厨流水线：请求体的“洗切配”

请求体进了厨房，就要开始预处理了。这里有几个关键工序：

1. 速度控制：别让客人嘴太快

client_body_timeout 60s;

这个计时器从接收第一个字节开始。如果客人60秒内没“说完”他的长篇需求，Nginx会礼貌打断：“先生，您能说重点吗？”然后关闭连接。对于慢速网络上传大文件，这个值要适当调大。

2. 健康检查：别什么垃圾都收

client_max_body_size 100m;

这是后厨的“最大接单量”。超过100MB的订单直接拒收：“抱歉，我们店小处理不了满汉全席”。特别是对公开接口，这个值必须设！否则黑客分分钟用1TB垃圾数据灌爆你的服务器。

3. 特殊需求处理

有些客人要求“拆包装”：

client_body_in_single_