fastcgi_cache_valid必须按http状态码、url路径和参数特征分层配置：200/301/302缓10–30分钟，404缓30秒–2分钟，500/502/503缓10–15秒，any兜底60秒；需置于location块内，配合fastcgi_cache_use_stale和fastcgi_ignore_headers等指令规避失效陷阱。
调整 fastcgi_cache_valid 不是给所有 PHP 响应统一设个“10分钟”，而是按状态码含义、URL 语义和数据新鲜度要求分层控制过期时间——它决定的是“什么内容缓多久”，直接关系到动态站的响应速度与数据一致性。
按 HTTP 状态码分层设有效期
不同状态码代表完全不同的业务场景，缓存时间必须差异化：
-
200 / 301 / 302：常规成功响应或稳定跳转，适合缓存 10–30 分钟。例如首页、文章页、固定分类页可设为
fastcgi_cache_valid 200 301 302 20m; -
404：页面暂不可用，缓太久会掩盖新上线动作，建议 30 秒–2 分钟，如
fastcgi_cache_valid 404 90s; -
500 / 502 / 503：后端故障响应，必须极短（10–15 秒），避免错误固化，例如
fastcgi_cache_valid 500 502 503 15s; - any：兜底规则，覆盖未显式声明的状态码，推荐设为 60 秒，防止意外响应长期滞留
按 URL 路径和参数特征缩放缓存窗口
同一状态码下，不同接口的数据敏感度差异极大，需在 location 块中单独配置：
- API 接口（如
/api/v1/user）返回 200 也只缓 60 秒，防数据 stale：location /api/ { fastcgi_cache_valid 200 60s; } - 搜索页（如
/search?q=xxx）即使 200，也应限制在 60 秒内，并确保$args在fastcgi_cache_key中 - 分页列表（如
/list?page=2）可保留$args，但把缓存周期缩短至 5 分钟，平衡性能与新鲜度 - 用户提交后的跳转页（如评论成功返回的 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 不被压垮
避开常见失效陷阱
配置写对了，但缓存不生效？往往卡在这几个关键点：
- fastcgi_cache_valid 必须放在 location 块内，写在 http 或 server 层无效
- 后端若返回
X-Accel-Expires头，会覆盖fastcgi_cache_valid，需加fastcgi_hide_header X-Accel-Expires; - PHP 返回
Cache-Control: no-cache或Set-Cookie时，Nginx 默认跳过缓存，必须配fastcgi_ignore_headers Cache-Control Expires Set-Cookie; - 缓存目录权限不对、
fastcgi_cache_key缺少$args或混入$cookie_*，都会导致命中率归零
