核心是避免php响应体写入磁盘临时文件，应根据业务p95响应大小合理设置fastcgi_buffers（如普通页面16 256k、导出页8 512k），并配套调整fastcgi_buffer_size、busy_buffers_size、max_temp_file_size等参数，最后通过文件监控、iotop和响应时间验证效果。
核心是让 PHP 响应体尽量留在内存里，避免写入 /var/cache/nginx/fastcgi_temp/ 这类路径下的临时文件。这不是错误，但频繁出现会拖慢响应、抬高磁盘 I/O，尤其在伪静态路由多、框架头大、或输出数据量大的场景下特别明显。
先确认是不是 fastcgi_buffers 触发的
打开 Nginx error.log，搜索关键词：
-
“upstream sent too big header” → 是
fastcgi_buffer_size不够，不是 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。
配套调 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 后，别只看日志停没停。实际验证三件事：
- 用相同 URL 多次请求，观察
fastcgi_temp/目录下是否有新增文件（ls -lt /var/cache/nginx/fastcgi_temp/） - 用
iotop -p $(pgrep nginx)查看 worker 进程是否还在高频刷磁盘 - 对比调优前后响应时间分布（特别是 P95/P99），重点看有没有明显抖动下降
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
