fastcgi_cache_valid必须在location块内按状态码和业务语义分层配置：200缓存1h，301/302缓存24h，404缓存1–5m，并配合fastcgi_no_cache、fastcgi_cache_use_stale等指令实现精准控制与高可用。
配置 fastcgi_cache_valid 不是简单写个“200 1h”，而是要按响应状态、业务语义和内容敏感度分层控制缓存生命周期。它必须出现在 location 块内，否则完全不生效——这是最常被忽略的硬性前提。
按 HTTP 状态码分级设置有效期
不同状态码代表不同业务含义，缓存时间应差异化：
-
200 OK：主页面、列表页等常规成功响应，建议缓存 30m～2h，如
fastcgi_cache_valid 200 1h; - 301/302：重定向响应通常稳定，可缓存更久（如 24h），避免反复查询后端路由逻辑
- 404 Not Found：错误页缓存太长会掩盖新上线内容，建议设为 1～5 分钟，既防爬虫暴力探测，又保证及时更新
- 403/401：权限类响应若由 PHP 统一生成，也可缓存 10m，减少鉴权逻辑重复执行
区分动态内容敏感度设定窗口
同一状态码下，不同页面的数据新鲜度要求不同：
- WordPress 首页、分类页可缓存 1h；但搜索页（
?s=xxx）需包含$args在fastcgi_cache_key中，并单独设为 10m，防止关键词过期后仍返回旧结果 - 用户评论提交后的跳转页（如
/wp-comments-post.php返回的 302）不应缓存，需用fastcgi_no_cache $request_uri显式排除 - 带登录态的页面（如
/wp-admin/）默认不进缓存，但若误配了fastcgi_cache，必须靠fastcgi_no_cache $cookie_logged_in拦截
配合 fastcgi_cache_use_stale 提升可用性
缓存过期 ≠ 服务不可用。用 fastcgi_cache_use_stale 定义“兜底场景”，让旧缓存继续服役：
-
fastcgi_cache_use_stale error timeout http_500 http_503;：后端挂了、超时或返回严重错误时，仍发已过期的缓存，避免雪崩 - 搭配
fastcgi_cache_lock on;可防止缓存失效瞬间大量请求穿透到 PHP-FPM - 注意：若后端返回
X-Accel-Expires头，它会覆盖fastcgi_cache_valid，此时需加fastcgi_hide_header X-Accel-Expires;抢回控制权
验证是否真正生效的关键检查点
仅靠 curl -I 看 X-FastCGI-Cache: HIT 不够，要确认三点：
- 缓存目录下是否有实际文件生成（
ls -l /tmp/wpcache/） - Nginx error.log 是否有
open() "/tmp/wpcache/..." failed (13: Permission denied)类报错 - 用
curl -I对同一 URL 连续请求两次，观察X-FastCGI-Cache从MIS变为HIT，且响应头中Age值递增
