调优 client_body_buffer_size 防止内存耗尽，核心是按业务类型分级设值：JSON API 用 16k，Base64 表单推荐 512k，大文件上传设 2m～4m 并隔离 location，IoT 小请求调至 4k；需算清并发内存账（如 2000 并发下建议 ≤256k），避开 Nginx 25% 余量机制导致的临界落盘，并同步配置 client_max_body_size、client_body_temp_path 和 client_body_timeout。
调优 client_body_buffer_size 防止内存耗尽，核心是控制每个请求独占的内存上限，避免高并发下 worker 进程被撑爆。它不是越大越好，而是要算清楚、分场景、卡边界。
按业务类型分级设值，不一刀切
不同请求对内存的实际需求差异极大，统一设大值等于主动让内存失控：
- 纯 JSON API（含 JWT、埋点数据）：请求体通常 ≤16KB，设
client_body_buffer_size 16k足够；压到8k或4k可释放内存给更多连接 - 带 Base64 图片的表单（如头像上传）：P95 实测常在 200–300KB 区间，按 P95 × 1.25 计算后向上取整，例如 320KB → 推荐设
512k，避开“差一点就落盘”的临界抖动 - 文档/压缩包上传接口：可设
2m～4m，但必须用独立location隔离，防止影响其他轻量路由 - 高并发小请求（如 IoT 心跳、前端埋点）：反而建议调小至
4k，降低单连接开销，提升整体吞吐
算清并发下的内存账，防雪崩
这个缓冲区是 per-request 分配的，不是共享池。设成 2MB，在 2000 并发上传时，仅此项就占用 4GB 物理内存：
- 估算公式：单 worker 可用内存 × 70% ÷ 预估最大并发上传数
- 示例：单 worker 可用内存 512MB，预期峰值上传并发 2000，则建议上限 ≤ 176KB，实际取
256k更稳妥 - 必须配合
worker_rlimit_as 512m限制单 worker 虚拟内存总量，防异常请求耗尽系统资源
避开 Nginx 内部余量机制触发的“卡边分配”
Nginx 实际分配时会自动加 25% 余量（size += size >> 2）。设 256k，它尝试按 320KB 分配；但若请求体正好是 319KB，仍走内存；一旦达到 320KB，就可能退回到按原始 256KB 分配，超出部分强制落盘：
- 实测最大请求体为 255KB，别设
256k，应上探至384k或直接512k - 前端统一限制上传 ≤512KB，Nginx 就设
512k；限制 ≤2MB，设2m即可，无需盲目堆到 8m+ - 禁用
client_body_in_file_only on—— 该指令会强制所有 body 写磁盘，让所有调优失效
必须同步检查的三项配套配置
只改 client_body_buffer_size 基本无效，以下三项缺一不可：
-
client_max_body_size必须 ≥ 缓冲区值，且与它同作用域（http/server/location），否则合法大请求直接被 413 拦截 -
client_body_temp_path目录需存在、worker 用户有读写权限、磁盘空间充足、I/O 延迟低（建议挂tmpfs或 SSD 分区） -
client_body_timeout设为10～60秒，防慢速上传长期霸占缓冲区，拖慢 worker 进程
