fastcgi_cache_valid需分层配置才能生效：按状态码（200/301/302设20m，404设90s，500/502/503设15s，any设60s）、路径特征（api设60s，分类页设30m等）及内容敏感度叠加判断，并配合cache_key、ignore_headers、use_stale等指令提升命中率与容错性。
fastcgi_cache_valid 不是设个统一时间就能起效的指令，它真正发挥作用的前提，是按业务含义把缓存周期“分层切开”——状态码、路径特征、内容敏感度，三者必须叠加判断。
按 HTTP 状态码分层设置有效期
不同状态码代表完全不同的服务语义，混用同一缓存时长会引发问题：
-
200/301/302：内容稳定、复用率高，适合设为 10–30 分钟（例如fastcgi_cache_valid 200 301 302 20m;） -
404：页面暂不可用，缓太久会掩盖新上线动作，建议设为 90 秒（fastcgi_cache_valid 404 90s;） -
500/502/503：后端故障响应，缓存会放大错误，必须极短（fastcgi_cache_valid 500 502 503 15s;） -
any：兜底规则，覆盖未显式声明的状态码，推荐设为 60 秒（fastcgi_cache_valid any 60s;），防止意外响应长期滞留
按 URL 路径与接口类型差异化控制
同一域名下，不同路径的数据更新节奏差异极大，需在独立 location 块中分别配置：
- API 接口（如
/api/v1/）：数据实时性要求高，建议fastcgi_cache_valid 200 60s; - 分类页或标签页（如
~ ^/(category|tag)/）：内容更新慢，可延长至30m - 搜索接口（如
/search?q=xxx）：即使返回200，也应限制在60s内，避免冷门词结果长期失效 - 用户提交跳转页（如
/wp-comments-post.php返回的302）：需用fastcgi_no_cache $request_uri;显式排除
配合 key 与 header 控制提升命中率与稳定性
光有 fastcgi_cache_valid 不够，必须同步处理缓存键和干扰头：
-
fastcgi_cache_key中包含$args，否则带参数的请求（如?s=nginx）全部命中同一缓存 - 加
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;，否则 PHP 输出的这些头会直接跳过缓存 - 若后端返回
X-Accel-Expires，它会覆盖fastcgi_cache_valid，此时需加fastcgi_hide_header X-Accel-Expires;
用 fastcgi_cache_use_stale 提升容错能力
缓存过期不等于服务中断：
-
fastcgi_cache_use_stale error timeout http_500 http_503;：后端挂了或超时，仍发已过期缓存 -
fastcgi_cache_use_stale updating;：最关键的一条——缓存刚过期、后台正在刷新时，先返回旧内容，再异步更新，彻底避免并发穿透 - 搭配
fastcgi_cache_lock on;可防止多个请求同时回源，保护 PHP-FPM 不被压垮
不复杂但容易忽略。
