用fastcgi_cache_valid实现时间阶梯策略，即按状态码（200/301/302缓10–30分钟、404缓30秒–2分钟、500/502/503缓10–30秒、any兜底1分钟）和请求特征（首页延长、分页缩至5分钟、搜索限60秒）分级设缓存时长，并配合fastcgi_cache_use_stale与cache_lock提升容错与并发控制。
用 fastcgi_cache_valid 实现时间阶梯策略，核心是按响应状态码和业务重要性分级设置缓存时长，避免“一刀切”，让高频但低敏感度的查询缓得久些，而异常或边缘响应缓得短些、及时刷新。
按状态码分层设定缓存有效期
不同 HTTP 状态码代表不同业务语义，应区别对待：
- 200/301/302：正常成功响应，内容稳定、复用率高，适合设为最长缓存期（如 10–30 分钟）
- 404：页面不存在，缓存过久会把“暂时下线”变成“永久消失”，建议设为 30 秒到 2 分钟
-
500/502/503：后端临时故障，缓存它们会放大错误影响，必须极短（如 10–30 秒），甚至配合
fastcgi_cache_use_stale控制降级行为 - any：兜底规则，覆盖未显式声明的状态码，建议设为 1 分钟，防止意外响应长期滞留
结合请求特征动态调整缓存粒度
单纯靠状态码还不够，高频查询常带参数（如分页、分类、搜索关键词），需配合 fastcgi_cache_key 和条件变量细化控制：
- 对无参首页或固定栏目页（如
/category/news），可延长缓存至 15m，并在fastcgi_cache_key中排除$query_string - 对带分页的列表页（如
/list?page=2），保留$query_string，但用fastcgi_cache_valid 200 5m缩短周期，平衡新鲜度与压力 - 对搜索接口（如
/search?q=nginx），即使返回 200，也建议设为fastcgi_cache_valid 200 60s，防止冷门词缓存堆积
用 fastcgi_cache_use_stale 补充阶梯容错能力
时间阶梯不只是“缓多久”，还包括“坏了还敢不敢用”。在缓存即将过期或后端不可用时，该指令能延续服务可用性：
-
fastcgi_cache_use_stale error timeout updating http_500;：当 PHP-FPM 崩溃或超时，仍可返回旧缓存，用户无感知 -
fastcgi_cache_use_stale updating;：特别关键——当缓存已过期但后台正在刷新，Nginx 可先发旧内容，再异步更新，避免并发穿透 - 搭配
fastcgi_cache_lock on;防止多个请求同时回源，进一步保护后端
验证与调优要点
阶梯策略是否生效，不能只看配置，要靠响应头和日志交叉验证：
- 加
add_header X-Cache "$upstream_cache_status";，观察命中状态：HIT、MISS、STALE、EXPIRED - 检查
fastcgi_cache_path下文件修改时间，确认不同状态码的缓存实际存续时长是否符合预期 - 监控 Nginx 的
cache manager日志，留意inactive清理是否频繁触发，若大量缓存未到fastcgi_cache_valid就被删，说明inactive设置过短
