增大 client_body_buffer_size 能明显提升上传性能，当上传文件普遍略超默认值（如8KB/16KB）又未达需分片程度时最有效：头像/Base64表单设512k可使95%+请求免落盘，JSON API设128k避免频繁写临时文件；但非“越大越好”，因其为per-request独占内存，盲目调大易耗尽worker内存，且必须同步满足client_max_body_size≥该值、client_body_temp_path可写低延迟、后端限制匹配三条件，并通过debug日志验证“buffered in memory”行为方可确认生效。
增大 client_body_buffer_size 能提升上传性能，但前提是它真正让请求体全程驻留内存——否则只是徒增内存开销，甚至引发稳定性风险。
什么时候能明显提效？
当上传文件大小普遍略超默认值（如 8KB 或 16KB），又未达到需分片或流式处理的程度时，调大该值效果最直接：
- 典型头像/Base64 表单（200KB–500KB）：从 16k → 设为 512k，可使 95%+ 请求免落盘，I/O 延迟下降 30%～50%
- JSON API 含长 JWT（80KB–120KB）：从默认 8k → 设为 128k，避免每次请求都写临时文件，降低磁盘 write/s 峰值
- 批量小图上传（如 5 张 × 300KB = 1.5MB）：设为 2m 可覆盖 P90 场景，减少临时文件生成频次与 inode 碎片
为什么不是“越大越好”？
该参数是 per-request 分配的内存缓冲区，不共享、不复用。盲目调大会快速吃光 worker 进程可用内存：
- 设为 4m，单 worker 并发处理 800 个上传连接 → 仅此项就占用约 3.2GB 内存
- 若客户端慢速上传（如弱网），buffer 会持续占用直到
client_body_timeout触发超时，加剧内存堆积 - 超出缓冲区的部分仍会落盘，但 buffer 过大却未覆盖主流尺寸，等于浪费内存换来了“伪优化”
必须同步生效的三项配置
单独改 client_body_buffer_size 几乎无效，以下三者缺一不可：
- client_max_body_size ≥ 缓冲区值：否则请求在读取前就被 413 拦截，buffer 根本没机会起作用
- client_body_temp_path 可写且低延迟：即使设了 4m，突发超大上传仍会落盘；路径若在机械盘或空间不足，直接报 500
-
后端服务限制匹配：如代理到 Spring Boot，需同步调大
server.tomcat.max-http-form-post-size；否则 Nginx 缓住了，后端却截断
怎么确认真有效？
不看配置是否加载成功，而要看运行态行为：
- 开启 debug 日志：
error_log /var/log/nginx/debug.log debug;，搜索 "http client request body buffered" —— 出现即走内存；若见 "temp file" 或 "buffered to a temporary file"，说明已落盘 - 监控
/var/tmp/nginx/client_body（或你设的路径）下文件生成频率：压测前后对比，明显减少才说明 buffer 起效 - 用
top -p $(pgrep nginx)观察 worker 进程 RSS 内存波动：稳定在合理区间，无持续攀升
