client_body_in_file_only是专为物理隔离大文件上传路径设计的精准指令，需在独立location块中启用，强制落盘并透传绝对路径给后端，由后端负责清理临时文件。
在高性能网关架构中，client_body_in_file_only 不是用来“提升性能”的通用开关，而是专为**物理隔离大文件上传路径、规避内存竞争与磁盘混用风险**而设的精准控制指令。它的价值不在于开启与否，而在于“何时开、开给谁、怎么收尾”——尤其适用于需长期驻留、审计留存或直通存储服务的长文件（如视频切片、日志归档包、合规备份等）。
只对明确路径启用，避免全局污染
该指令必须限定在独立 location 块内，且仅匹配已知的大文件上传端点。不能放在 http 或 server 级，更不可嵌套在 if 中（Nginx 会直接报错）。
- 例如：专设
location /ingest/archive处理归档上传，而非泛用location /upload - 配合
client_max_body_size显式设为业务最大值（如2g），防止误传小请求被强制落盘 - 禁用无关指令干扰：不配
client_body_buffer_size（它在此模式下失效），也不启用underscores_in_headers等无关设置
强制落盘 + 显式路径 + 文件句柄透传
启用后，Nginx 不再尝试内存缓冲，所有请求体一律写入磁盘临时文件，并通过 $request_body_file 变量将**绝对路径**传递给后端（仅限 proxy_pass 场景）。
-
client_body_temp_path /data/nginx/body_temp/ 1 2;—— 指向专用 SSD 分区或 tmpfs，避免与系统盘或日志盘争 I/O -
client_body_in_file_only on;—— 确保即使请求体只有几 KB，也走文件路径（实现行为一致性和可预测性） -
proxy_set_header X-Body-File $request_body_file;—— 后端据此直接open()文件，跳过 HTTP body 解析，降低 CPU 和内存压力
隔离清理策略，防止磁盘泄漏
该模式下 Nginx 不自动删除临时文件，必须由后端或外部机制负责回收。这是物理隔离的关键一环。
- 设为
client_body_in_file_only clean;仅适用于短时中转场景（如代理到对象存储后立即删），不适用于需保留原始文件的归档流程 - 推荐设为
on，由后端服务在成功处理后返回确认码，再由定时任务扫描X-Body-File路径并安全清理 - 临时目录需配置独立磁盘配额（如
quota或prlimit），避免单次异常上传占满整个分区
与响应式网关协同，避免双重缓冲
若上游是 Spring Cloud Gateway 或其他响应式网关，它本身不识别 client_body_in_file_only。此时需分层处理：
- Nginx 层专注“接收+落盘+透传路径”，不做任何 body 解析或重写
- 响应式网关收到带
X-Body-File的请求后，直接用Files.readAllBytes()或AsynchronousFileChannel流式读取，不加载进堆内存 - 禁止在网关层使用
ModifyRequestBody等需读取 body 的过滤器——它会触发二次读取，破坏文件路径有效性
