fastcgi_cache_valid需按状态码分层设有效期（200/301/302设20m、404设90s、500/502/503设15s、any设60s），结合URL路径与参数动态调整缓存周期，并用fastcgi_cache_use_stale提升容错能力。
fastcgi_cache_valid 不是简单设个“200 1h”就能管用的指令，它真正的价值在于按响应语义做分层控制——状态码类型、请求路径特征、容错场景三者叠加，才能让缓存既快又稳。
按状态码分级设定过期时间
不同状态码代表完全不同的业务含义，缓存周期必须差异化：
-
200 / 301 / 302：内容稳定、复用率高，建议设为 10–30 分钟，例如
fastcgi_cache_valid 200 301 302 20m; -
404：页面暂不可用，缓太久会掩盖上线或修复动作，推荐 30 秒–2 分钟，例如
fastcgi_cache_valid 404 90s; -
500 / 502 / 503：后端临时故障，缓存会放大错误影响，必须极短，例如
fastcgi_cache_valid 500 502 503 15s; - any：兜底规则，覆盖未显式声明的状态码，设为 60 秒较稳妥，防止意外响应长期滞留
结合 URL 路径与参数动态缩放周期
同一状态码下，不同请求的数据敏感度差异很大，需配合 fastcgi_cache_key 和条件变量细化控制：
- 无参首页或固定栏目页（如
/category/news），可延长至 15 分钟，并在 key 中排除$query_string - 带分页的列表页（如
/list?page=2），保留 query string，但将 200 缓存缩至 5 分钟，兼顾新鲜度与压力 - 搜索接口（如
/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 不够，要交叉验证：
- 加
add_header X-Cache "$upstream_cache_status";，观察命中状态：HIT、MISS、STALE、EXPIRED - 检查缓存目录下文件修改时间：
ls -l /www/server/nginx/fastcgi_cache/，确认不同状态码的缓存实际存续时长是否符合预期 - 连续两次请求同一 URL，确认
X-Cache从MIS变为HIT，且响应头中值递增
