fastcgi_cache_revalidate 是 nginx 1.11.10+ 实现条件式缓存刷新的指令，通过向后端发送带 if-modified-since 或 if-none-match 的校验请求，依据 304 或 200 响应决定复用或更新缓存，并需配合 fastcgi_cache、缓存头及 stale 机制使用。
fastcgi_cache_revalidate 是 Nginx 1.11.10+ 引入的一个关键配置指令，用于在启用 FastCGI 缓存时，实现「条件式缓存刷新」——即不直接失效整个缓存项，而是通过向后端发起一次轻量级校验请求（HEAD 或 GET），仅当后端返回 304 Not Modified 时才复用旧缓存；若返回新内容（如 200），则自动更新缓存并返回新响应。它本质是将 HTTP 协议的 If-Modified-Since 和 If-None-Match 机制与 Nginx 缓存生命周期深度集成。
启用 revalidate 的前提条件
该功能不是开箱即用，需同时满足以下三点：
- 启用
fastcgi_cache并设置有效缓存区（如fastcgi_cache my_cache;） - 开启
fastcgi_cache_revalidate on; - 后端（如 PHP-FPM）必须正确输出标准缓存控制头：
Last-Modified或ETag（至少其一），且响应状态码支持 304
revalidate 的实际工作流程
当一个已缓存的响应即将过期（或已过期但配置了 fastcgi_cache_valid 200 1h + fastcgi_cache_use_stale updating），Nginx 不会直接丢弃缓存，而是：
- 构造一次上游校验请求：自动带上
If-Modified-Since（基于原响应的Last-Modified）或If-None-Match（基于原响应的ETag） - 发送该请求至 FastCGI 后端（注意：仍是 FastCGI 协议，非 HTTP；PHP 中可通过
$_SERVER['HTTP_IF_MODIFIED_SINCE']等获取） - 若后端返回 304，Nginx 延长该缓存项 TTL，并直接返回原缓存内容（含原始响应头）
- 若后端返回 200（含新
Last-Modified/ETag），Nginx 更新缓存内容与元数据，再返回新响应
配合 stale 状态实现无感更新
单独使用 revalidate 可能导致用户等待校验完成。推荐搭配 fastcgi_cache_use_stale updating：
- 当缓存项处于「正在被 revalidate 校验中」状态时，Nginx 可立即返回旧缓存（stale），避免阻塞用户
- 后台异步完成校验与更新，下次请求即可拿到新鲜内容
- 这对高并发、内容更新不频繁但要求强一致性的场景（如文章详情页）非常实用
后端需适配的关键点
PHP 示例逻辑（伪代码）：
// 检查 If-Modified-Since
if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) &&
strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) >= $last_modified_time) {
header('HTTP/1.1 304 Not Modified');
exit;
}
// 检查 If-None-Match（ETag）
if (isset($_SERVER['HTTP_IF_NONE_MATCH']) &&
$_SERVER['HTTP_IF_NONE_MATCH'] === $etag) {
header('HTTP/1.1 304 Not Modified');
exit;
}
// 正常输出内容，并设置头
header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $last_modified_time) . ' GMT');
header('ETag: "' . $etag . '"');
echo $content;
务必确保 Last-Modified 时间精确到秒、ETag 全局唯一且稳定（如基于内容哈希或数据库更新时间戳），否则 revalidate 会失效或误判。
