关键是要让大报文请求尽量走内存、少写磁盘，需依据真实请求体p95/p99分布精准设置client_body_buffer_size，避开nginx 25%安全扩容触发的临界点，并控制单连接内存开销。
让大报文请求尽量走内存、少写磁盘，关键不是盲目调大 client_body_buffer_size，而是让它精准覆盖真实请求体的 P95/P99 分布，并避开 Nginx 内部 25% 安全扩容机制触发的临界点，同时控制单连接内存开销不挤占整体资源。
看真实分布，别信平均值
日志里平均上传大小是 100KB，不代表调成 128k 就够用。Nginx 实际分配逻辑会加 25% 余量：若某请求体为 255KB，配置 256k 时，255 × 1.25 ≈ 319k > 256k，仍可能落盘。必须统计成功请求中的 Content-Length 分位值：
- 从 access log 或前端埋点中提取真实 body 大小，重点看 P95（95% 请求 ≤ X）和 P99
- 若 P95 是 320KB，稳妥做法是设为 512k 或直接 1m，跳过临界区
- 纯 JSON + JWT 头：64k～128k 足够；含 Base64 小图表单：≥128k，256k 更稳；文档/压缩包类（≤20MB）：2m～4m 可行，但需后端能接住
避开“差一点就落盘”的临界陷阱
Nginx 不按配置值硬切，而是在已知长度（有 Content-Length）时做一次“安全尝试”：
- 若请求体 ≤
client_body_buffer_size × 1.25，则按实际长度分配缓冲区 - 否则，直接按配置值分配；超出部分一律写入
client_body_temp_path - 举例：设为 256k，实测最大请求体 255KB → 因 255 × 1.25 > 256，仍可能写临时文件；改设为 384k 或 512k 才可靠
控内存总量，防高并发下被拖垮
每个连接独占一份缓冲区内存，设得过大容易引发内存压力：
- 设为 1m，在 3000 并发时就额外吃掉 3GB RAM
- 轻量 API（高频 JSON）：保持默认 8k 或调小到 4k，省内存保连接数
- 中低频大报文（如后台上传接口）：可设 512k～2m，建议用独立
location隔离，避免影响其他路由 - 务必禁用
client_body_in_file_only on，防止误开强制落盘
验证是否真走内存，别只看配置
改完不验证，等于没调：
- 开启 debug 日志：
error_log /var/log/nginx/debug.log debug;，搜索 "client request body buffered" 或 "in memory" - 压测时用
iostat -x 1观察client_body_temp_path所在磁盘的write/s是否明显下降 - 检查临时目录下文件创建频次（如用 inotify 或 Prometheus），归零才算到位
