fastcgi_cache_valid 是按http状态码分层控制缓存生命周期的核心指令，需在location块内配置，并协同cache_key、ignore_headers等指令；200缓存30min–2h，301/302缓存24h，404缓存1–5min，401/403缓存10min，any兜底设1min；需结合url特征细化粒度并用use_stale提升韧性。
fastcgi_cache_valid 不是“设个时间就完事”的开关，而是按状态码语义和业务敏感度分层控制缓存生命周期的核心指令。它必须写在 location 块内才生效，且需与 fastcgi_cache_key、fastcgi_ignore_headers、fastcgi_no_cache 等协同工作，否则配置等于白写。
按 HTTP 状态码分级设定有效期
不同状态码代表完全不同的业务含义，缓存时间必须差异化：
-
200 OK：常规成功响应（如文章页、分类页），内容稳定但非永久不变，建议 30 分钟～2 小时；例如
fastcgi_cache_valid 200 1h -
301/302：重定向逻辑通常长期有效，可缓存 24 小时，减少后端路由判断压力；例如
fastcgi_cache_valid 301 302 24h -
404：错误页缓存过久会掩盖新上线页面，建议 1～5 分钟；例如
fastcgi_cache_valid 404 3m -
401/403：若由 PHP 统一鉴权生成，可缓存 10 分钟，避免重复执行权限校验；例如
fastcgi_cache_valid 401 403 10m -
any：兜底规则，覆盖未显式声明的状态码，建议设为 1 分钟，防止异常响应滞留；例如
fastcgi_cache_valid any 1m
结合请求特征细化缓存粒度
同一状态码下，不同 URL 的数据新鲜度要求差异很大，需靠条件变量+缓存键配合控制：
- 首页、固定栏目页（无参数）可延长缓存，如
fastcgi_cache_valid 200 15m，并在fastcgi_cache_key中排除$args - 分页列表页（如
/list?page=2）保留$args，但缩短有效期至 5 分钟，平衡并发与及时性 - 搜索页（如
/search?q=nginx）即使返回 200，也应限制为 60 秒，防止冷门词缓存堆积 - 用户提交后的跳转页（如
/wp-comments-post.php返回的 302）必须用fastcgi_no_cache $request_uri显式排除
用 fastcgi_cache_use_stale 提升服务韧性
缓存过期不等于服务中断。该指令让 Nginx 在后端不可用或刷新中仍能提供可用响应：
-
fastcgi_cache_use_stale error timeout http_500 http_503：后端崩溃、超时或返回严重错误时，继续发已过期缓存，避免雪崩 -
fastcgi_cache_use_stale updating：关键配置——当缓存已过期但后台正在重建，Nginx 先返回旧内容，再异步更新，彻底规避并发穿透 - 搭配
fastcgi_cache_lock on，防止多个请求同时回源，进一步保护 PHP-FPM
验证是否真正生效的三个硬指标
仅看 X-FastCGI-Cache: HIT 不够，必须交叉验证：
- 检查缓存目录下是否有文件生成：
ls -l /www/server/nginx/fastcgi_cache/（路径以你配置为准） - 排查权限报错：
grep "Permission denied" /www/server/nginx/logs/error.log，确认 Nginx 工作用户（如 www）有读写权限 - 连续两次请求同一 URL，观察响应头中
X-FastCGI-Cache从MIS变为HIT，且Age值递增
