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，但用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值递增 - 查看 Nginx 错误日志，排除
Permission denied或open() failed类权限问题
