fastcgi_cache_valid 必须在启用 fastcgi 缓存的 location 块内配置，按状态码分层设置过期时间（如 200/301/302 缓存 20m，404 缓存 90s，500/502/503 缓存 15s），并配合 fastcgi_cache_use_stale 提升容错能力。
在 Nginx 中，fastcgi_cache_valid 不能只写 200 1h 就完事。它真正的价值在于按响应状态码的业务含义，分层设置过期时间——不同状态码代表完全不同的语义，缓存策略必须差异化。
必须放在 location 块内才生效
该指令只有出现在启用 FastCGI 缓存的 location 块中才会起作用。如果只写在 http 或 server 块顶层，配置将被忽略。
- 确保该 location 已启用缓存：
fastcgi_cache my_cache; - 确保已通过
fastcgi_cache_path定义了名为my_cache的缓存区 - 若后端 PHP 返回
Set-Cookie或Cache-Control: no-cache，需配合fastcgi_ignore_headers Set-Cookie Cache-Control;否则默认不缓存
按状态码分层设有效期（推荐组合）
每条 fastcgi_cache_valid 指令可指定多个状态码 + 一个时间值，Nginx 会精确匹配最具体的规则：
-
fastcgi_cache_valid 200 301 302 20m;—— 主内容与重定向稳定，适合中等时长缓存 -
fastcgi_cache_valid 404 90s;—— 防爬虫探测，但太长会掩盖新上线页面 -
fastcgi_cache_valid 500 502 503 15s;—— 后端故障类错误，必须极短，避免用户长时间看到错误页 -
fastcgi_cache_valid any 60s;—— 兜底规则，覆盖未显式声明的状态码（如 403、410），不影响已有规则
配合 fastcgi_cache_use_stale 提升容错能力
缓存过期或后端异常时，Nginx 可返回“陈旧”缓存继续服务，避免雪崩：
fastcgi_cache_use_stale error timeout invalid_header http_500 http_502 http_503;- 搭配
fastcgi_cache_valid 500 502 503 15s;，既限制错误页缓存时长，又允许在后端恢复前短暂兜底 - 还可加
updating，让后台更新缓存时仍返回旧内容，提升并发响应能力
验证是否按预期工作
加一行头信息便于调试：
add_header X-Cache-Status $upstream_cache_status;- 用
curl -I多次请求同一 URL，观察X-Cache-Status是HIT、MISS还是EXPIRED - 检查 Nginx error log（debug 级别）中是否有
cached response expired或using stale cache记录
