fastcgi_temp_path不参与缓存，仅作响应体超内存时的临时磁盘兜底；真正优化应聚焦fastcgi_buffers等参数确保响应全程驻留内存，避免触发temp_path写入，从而消除I/O延迟、稳定TTFB。
fastcgi_temp_path 本身不参与“缓存”，它只负责暂存超出内存缓冲区的响应体数据——当 fastcgi_buffers 不够用时，Nginx 才会把剩余内容写入该路径下的临时文件。所谓“平滑暂存并安全写入缓存”，本质是避免走到这一步；真走到这步，说明调优已失效，性能已受损。
所以真正要做的，不是优化 fastcgi_temp_path，而是让它几乎不被使用。以下是关键操作逻辑：
明确 fastcgi_temp_path 的定位与风险
- 它只是“兜底路径”，不是缓存路径（
fastcgi_cache_path才是） - 写临时文件 = 磁盘 I/O = TTFB 波动、延迟飙升、小文件碎片、磁盘满风险
- 常见报错如
upstream sent too big response while reading response from upstream或using temporary file都指向它被触发
优先堵住源头：让响应体全程驻留内存
核心动作是调准 fastcgi_buffers 及关联参数，确保典型大响应（如 2MB 报表）完全装得下：
- 实测 P95 响应体大小（用
curl -s -w "%{size_download}" -o /dev/null URL） - 设
fastcgi_buffers N 64k，使N × 64k ≥ P95 size（例如 2MB → 至少 32 个） - 同步设
fastcgi_buffer_size ≤ 64k（建议 16k，只存响应头） - 设
fastcgi_busy_buffers_size = 128k、fastcgi_temp_file_write_size = 128k，防止小块刷盘
✅ 正确效果：error.log 里不再出现
temporary file相关日志，strace 也看不到对fastcgi_temp路径的 write/openat 调用。立即学习“PHP免费学习笔记（深入）”；
若仍需配置 fastcgi_temp_path（仅作兜底保障）
仅在以下情况才需关注它：
- 服务器偶尔处理超预期巨量响应（如异常导出、调试接口）
- 你无法控制 PHP 输出大小（第三方模块、无分页导出）
此时应：
- 路径必须和
fastcgi_cache_path在同一磁盘分区（否则缓存回写失败） - 目录需由 Nginx 工作进程用户（如
www-data或nginx）可读写 - 建议单独挂载一块 SSD 分区（如
/var/tmp/nginx-fastcgi），避免和系统盘争 IO - 不必设多级目录（
levels=1:2对 temp_path 无效），简单路径即可：fastcgi_temp_path /var/tmp/nginx-fastcgi;
不要混淆：temp_path ≠ cache_path
-
fastcgi_cache_path是主动缓存机制，用于复用已生成的响应（需配合fastcgi_cache指令启用） -
fastcgi_temp_path是被动溢出机制，纯属 fallback，不会提升性能，只会降低下限 - 即便你开了
fastcgi_cache，大响应仍可能先经过temp_path再落盘到cache_path—— 这过程不可控且低效
真正安全、平滑、高性能的做法，就是让大响应从 PHP 出来后，全程走内存缓冲，一气呵成送到客户端。fastcgi_temp_path 的存在意义，只是防止崩，而不是用来靠。
