fastcgi_cache_valid需按状态码分级、路径参数适配、容错协同三方面精细配置：200/301/302设20m，404设90s，500/502/503设15s，any兜底60s；结合map动态设cache_ttl；配合use_stale实现错误/过期时降级可用。
fastcgi_cache_valid 不是简单设个“200 1h”就能起效的指令，它真正的作用是按响应语义做分层、动态、可兜底的缓存时段控制。精确定义的关键在于三件事：状态码分级、路径与参数适配、容错机制协同。
按状态码分层设定有效期
不同状态码代表完全不同的业务含义，缓存时间必须差异对待，不能统一设为“10分钟”：
200/301/302：内容稳定、用户高频访问，适合设为 10–30 分钟
例如：fastcgi_cache_valid 200 301 302 20m;404：页面暂不可用，缓太久会掩盖发布或修复动作，建议 30 秒到 2 分钟
例如：fastcgi_cache_valid 404 90s;500/502/503：后端临时故障，缓存会放大错误，必须极短——10–30 秒
例如：fastcgi_cache_valid 500 502 503 15s;any：兜底规则，覆盖未显式声明的状态码（如 403、410、307），推荐设为 60 秒，防止异常响应长期滞留
例如：fastcgi_cache_valid any 60s;
注意：这些规则按顺序匹配，先写的优先级更高；
any应放在最后，否则会覆盖前面的具体状态码设置。
结合请求路径与参数动态缩放
同一状态码下，不同 URL 的数据敏感度差异巨大，需配合 fastcgi_cache_key 和条件变量联动调整：
- 首页或固定栏目页（如
/、/category/news）：无参、更新频率低，可延长缓存至15m，并在 key 中排除$args - 分页列表页（如
/list?page=2）：保留$args，但将200缓存缩至5m，兼顾新鲜度与压力 - 搜索接口（如
/search?q=nginx）：即使返回200，也应限制为60s，避免冷门词缓存堆积 - 后台或登录相关路径（如
/admin/、/user/profile）：建议直接fastcgi_cache_bypass，不进缓存
实现方式依赖 map 预处理或 if（慎用）+ fastcgi_cache_valid 条件嵌套，例如：
map $request_uri $cache_ttl {
~^/$ "15m";
~^/category/ "10m";
~^/list\?page= "5m";
~^/search\? "60s";
default "20m";
}
fastcgi_cache_valid 200 $cache_ttl;用 fastcgi_cache_use_stale 补齐时间阶梯
缓存时段不仅决定“缓多久”，还决定“坏了敢不敢用”：
fastcgi_cache_use_stale error timeout http_500;
当 PHP-FPM 崩溃、超时或返回 500，Nginx 仍可返回旧缓存，用户无感知fastcgi_cache_use_stale updating;
关键能力：缓存过期时若后台正在刷新，Nginx 先发旧内容，再异步更新，避免并发穿透可叠加使用：
fastcgi_cache_use_stale error timeout updating http_500 http_502;
搭配 fastcgi_cache_lock on; 还能防止多个相同请求同时回源，进一步保护后端。
不复杂但容易忽略
