核心是让PHP响应体全程驻留内存，避免写入fastcgi_temp_path临时文件；需实测P95响应体大小，合理配置fastcgi_buffers、fastcgi_buffer_size、fastcgi_busy_buffers_size和fastcgi_temp_file_write_size，并验证error.log无临时文件警告及strace无相关磁盘写入。
核心是让 PHP 响应体尽量留在内存里，避免写入 /var/cache/nginx/fastcgi_temp/ 这类路径下的临时文件。这不是错误，但频繁落盘会拖慢响应、抬高磁盘 I/O，尤其在框架头大、伪静态路由多或输出数据量大的场景下特别明显。
先确认是不是 fastcgi_buffers 触发的
打开 Nginx error.log，搜索关键词：
-
“upstream sent too big header” → 是
fastcgi_buffer_size不够，不是fastcgi_buffers主体问题 - “an upstream response is buffered to a temporary file” + 路径含 fastcgi:// → 确实是响应体超出内存缓冲，已落盘
- 同时出现 “client request body is buffered” → 那是上传请求导致的，要查
client_body_*，和fastcgi_buffers无关
按业务响应规模设对 fastcgi_buffers
别套用“64 128k”这种通用值。先看你的 PHP 应用典型响应体大小（比如导出页、报表接口、列表页），取 P95 值再加 20% 余量：
- 普通 Laravel / ThinkPHP 页面（含调试头、JWT Cookie）：平均 120–300KB → 推荐
fastcgi_buffers 16 256k（共 4MB） - 日志导出或 CSV 下载（几 MB）：P95 约 3MB →
fastcgi_buffers 8 512k（共 4MB）更稳，单块更大利于内核处理 - 视频流或持续大输出：直接关缓存，
fastcgi_buffering off，此时 buffers 参数失效
注意：fastcgi_buffer_size 只管响应头和第一段响应体，必须 ≤ 单个 fastcgi_buffers 大小。例如设了 fastcgi_buffers 16 256k，fastcgi_buffer_size 最大只能设到 256k。
立即学习“PHP免费学习笔记（深入）”；
配套调 busy 区与临时文件策略
光加 buffers 不行，还要控制“已收未发”的数据上限和落盘行为：
-
fastcgi_busy_buffers_size设为总缓冲量的 1/2～2/3，比如上例 4MB 缓冲，可设2m或3m；不能超过总和，否则 Nginx 启动失败 -
fastcgi_max_temp_file_size不建议设 0（会丢请求），对多数业务设1024m较稳妥；若确定不接受落盘，才设 0 并配合监控 502 -
fastcgi_temp_file_write_size提高到256k，减少 write() 系统调用次数，缓解小 IO 压力 - 临时目录若在机械盘或空间紧张，把
fastcgi_temp_path指向 SSD 分区或/dev/shm（如fastcgi_temp_path /dev/shm/nginx_fcgi_temp 1 2）
验证是否真正绕开磁盘瓶颈
改完配置 reload Nginx 后，别只看服务是否启动，要实测响应行为：
- 用
curl -s -w "\n%{size_download}\n" -o /dev/null http://yoursite/api/data查看典型响应体字节数，确认其稳定落在number × size范围内 - 检查 Nginx error log 是否还有
upstream sent too big response或using temporary file类警告 - 用
iotop或strace -p $(pgrep nginx) -e trace=write,openat观察是否仍有对fastcgi_temp路径的写入行为
