fastcgi_cache_path 是 Nginx FastCGI 缓存的基石指令，需协同配置物理路径（如 /www/server/nginx/cache/fastcgi）、levels=1:2 避免 inode 过载、keys_zone 按业务设内存（如 wp_cache:256m）、use_temp_path=off 防写入失败，并确保 www 用户完全掌控权限。
fastcgi_cache_path 不是简单指定一个文件夹，而是整套缓存层存储方案的起点。它直接决定缓存能否稳定写入、高并发下是否卡顿、百万级页面能否快速命中。
物理路径必须真实、专用、权限可控
缓存目录不能是临时路径（如 /tmp）、系统挂载点（如 /dev/shm）或相对路径。推荐用 Nginx 环境下的专用子目录：
- 宝塔用户：/www/server/nginx/cache/fastcgi
- phpEnv 用户：/www/phpenv/nginx/fastcgi_cache
- 手动部署：/var/cache/nginx/fastcgi
创建后必须确保 Nginx 工作进程用户（通常是 www 或 nginx）拥有完整控制权：
sudo mkdir -p /www/server/nginx/cache/fastcgi sudo chown -R www:www /www/server/nginx/cache/fastcgi sudo chmod -R 755 /www/server/nginx/cache/fastcgi
验证是否真正可写：运行 sudo -u www touch /www/server/nginx/cache/fastcgi/test，无报错才算通过。
levels=1:2 是性能刚需，不是可选参数
这个参数控制缓存文件的目录层级结构。不设或设为 levels=0，所有缓存会挤进单个目录，inode 耗尽后写入失败，高并发时响应明显变慢。
- levels=1:2 → 生成两级子目录，如 a/ab/xxx，支持百万级缓存项仍保持低延迟
- levels=1:1:2 → 三级结构，适用于超大规模站点（如日均百万 PV 的 WordPress）
实际效果：10 万缓存项下，levels=1:2 的平均查找耗时约 0.08ms；levels=0 则可能升至 5ms 以上。
keys_zone 内存区大小需匹配业务规模
keys_zone 存储的是缓存键（key）的元信息（哈希值、过期时间、状态等），不存原始内容。内存不足会导致 key 频繁淘汰，缓存命中率断崖下跌。
- 小型博客或企业站：128M～256M（如 keys_zone=wp_cache:256m）
- 中大型电商或资讯站：384M～512M
- 超大流量站点：1G+，但需确认服务器总内存余量充足
注意：该内存由 Nginx 主进程分配，重启后重建，不随 worker 进程变化。建议预留至少 20% 内存冗余。
use_temp_path=off 必须启用
默认 use_temp_path=on，Nginx 先把响应写到临时目录（如 /tmp），再 move 到缓存目录。这在高并发或磁盘 I/O 压力大时极易失败，出现“502 Bad Gateway”或缓存静默失效。
- 设为 use_temp_path=off 后，响应直接写入目标缓存路径，规避中间环节风险
- 前提是缓存路径所在分区有足够空间且 I/O 性能稳定（SSD 优于 HDD）
配合 max_size 和 inactive 参数，可形成闭环清理机制：max_size 控制磁盘上限，inactive 清理长期未访问项，避免缓存无限膨胀。
