fastcgi_cache_valid必须在location块内按状态码语义分层配置（200/301/302缓20m、404缓90s、500/502/503缓15s、any兜底60s），结合url路径与参数动态调控，并配合fastcgi_cache_use_stale和fastcgi_cache_lock实现容错与并发控制。
fastcgi_cache_valid 不是设个固定时间就完事的指令，它真正起作用的前提是：按状态码语义分层、结合请求特征动态调控、并配合容错机制形成闭环。配置位置必须在 location 块内，否则完全不生效。
按 HTTP 状态码分层设置有效期
不同状态码代表不同业务含义，缓存周期必须差异化：
-
200 / 301 / 302：内容稳定、复用率高，建议设为 10–30 分钟，例如
fastcgi_cache_valid 200 301 302 20m; -
404：页面暂不可用，缓太久会掩盖新上线动作，推荐 90 秒，例如
fastcgi_cache_valid 404 90s; -
500 / 502 / 503：后端故障响应，必须极短（10–30 秒），避免错误放大，例如
fastcgi_cache_valid 500 502 503 15s; - any：兜底规则，覆盖未显式声明的状态码，建议设为 60 秒，防止意外响应长期滞留
结合 URL 路径与参数动态缩放周期
同一状态码下，不同请求的数据敏感度差异很大，需靠 fastcgi_cache_key 和条件变量协同控制：
- 无参首页或固定栏目页（如
/category/news），可延长至 15 分钟，并在 key 中排除$args - 带分页的列表页（如
/list?page=2），保留$args，但单独设fastcgi_cache_valid 200 5m - 搜索接口（如
/search?q=nginx），即使返回 200，也只缓 60 秒，防冷门词堆积 - 用户提交跳转页（如评论成功后的 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-Cache: HIT 不够，要交叉验证：
- 检查缓存目录下是否有对应文件生成：
ls -l /www/server/nginx/fastcgi_cache/，观察修改时间是否符合预设周期 - 连续两次请求同一 URL，确认
X-Cache从MIS变为HIT，且响应头中Age值递增 - 加
add_header X-Cache "$upstream_cache_status";，观察命中状态：HIT、MISS、STALE、EXPIRED
