前端缓存策略

浏览器缓存难题：为何总是显示旧版本？

王圆圆

21 Jul 2025 — 6 min read

Web Cookies Sync error

作为前端开发者，你是否曾在发布新版本后，遇到这样的反馈：“更新后依然是旧版本，页面没有变化”？无论你怎么通知用户清除缓存，或者让他们切换到无痕模式，浏览器似乎总是坚持用老版本的文件。这个问题不仅仅存在于 Webpack 更新后的前端应用，任何前端应用在更新后都有可能遇到类似的缓存问题。

本文将深入分析为何你精心设计的缓存策略并未如预期工作，背后的根源到底在哪里，并提供一份可操作的 Nginx 配置方案，确保每次发布都能顺利自动更新，用户体验无感知。

一、为何会发生缓存失效？——缓存策略的表象与真实行为

在我们分析如何解决这个问题之前，先来看看大多数前端开发者常用的缓存策略，这些策略看似“完美无缺”：

为静态资源文件名加上哈希值
使用 Webpack 等工具，我们会给 JavaScript、CSS 文件等静态资源添加一个哈希值（例如：main.58d91471.js）。理论上，这样一来，每次文件内容发生变化时，哈希值也会变化，浏览器就能识别到资源更新，并重新请求最新文件。

为 HTML 设置防缓存的 meta 标签
我们通常会在 index.html 的 <head> 部分加入以下 meta 标签，目的是强制浏览器每次都从服务器获取最新的 HTML 文件：

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">

这些策略看起来完美无缺，问题也应该得到解决。理论上，浏览器应该每次都获取到最新的 index.html 文件，进而加载新版本的资源，用户看到的是最新的页面。然而，实际情况往往并非如此。

二、问题的根源：浏览器缓存策略的优先级与 Nginx 默认配置

为何这些策略未能如期发挥作用？问题的关键在于浏览器缓存的优先级：HTTP 响应头的缓存指令优先于 HTML 的 meta 标签。

简单来说，meta 标签所做的“建议”并非浏览器必须遵循的硬性规定，而是服务器通过 HTTP 响应头（如 Cache-Control 和 Expires）返回的指令才是浏览器最终会执行的内容。

罪魁祸首：Nginx 的默认行为

我们来看一下典型的 Nginx 配置：

# 处理静态资源的缓存策略
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg)$ {
    expires 1d;
    add_header Cache-Control "public, max-age=86400";
}

# 处理所有请求并返回 index.html
location / {
    try_files $uri $uri/ /index.html;
}

在这个配置中，静态资源（如 JS、CSS）有明确的缓存策略，但是针对 index.html 文件，Nginx 没有设置任何缓存控制指令。这就意味着：

当浏览器访问 https://yoursite.com/ 时，它会命中 location / 规则。
Nginx 返回 index.html 文件，但没有附带任何缓存控制头信息。
由于没有明确的缓存指令，浏览器或 CDN 会根据默认策略缓存这个 HTML 文件。
当你发布新版本后，JS 文件名（例如 main.new-hash.js）虽然变了，但用户再次访问时，浏览器直接从缓存中取出了旧的 index.html。
旧的 HTML 文件依然引用着旧的 JS 文件（main.old-hash.js）。
最终，用户看到的还是旧版本。

整个流程形成了一个完美的闭环，meta 标签在其中毫无存在感。

三、解决方案：精细化的 Nginx 缓存配置

既然问题源于 Nginx 缺乏对 index.html 文件的缓存控制，那我们就可以通过调整 Nginx 配置来解决。以下是一个经过实战验证的配置方案：

server {
    listen 80;
    server_name your.domain.com;  # 替换为你的域名
    root /usr/share/nginx/html;  # 替换为你的项目根目录

    # 规则1：HTML 文件 - 永不缓存
    location = /index.html {
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Pragma "no-cache";
        add_header Expires "0";
    }

    # 规则2：带 Hash 的静态资源 - 永久缓存
    location ~* \.[a-f0-9]{8}\.(css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # 规则3：其他静态资源（如图片、字体） - 长期缓存
    location ~* \.(jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$ {
        expires 30d;
        add_header Cache-Control "public";
    }

    # 规则4：单页应用（SPA）路由处理
    location / {
        try_files $uri $uri/ /index.html;
    }
}

Nginx config

配置解读：

location = /index.html：确保 index.html 文件每次都从服务器加载，不被缓存。
location ~* \.[a-f0-9]{8}\.(css|js)$：为带有哈希值的 JS 和 CSS 文件设置长期缓存（1 年），并使用 immutable 属性，表示这些文件永远不会变化。
location /：作为单页应用（SPA）的路由处理，所有未匹配的请求都会指向不缓存的 index.html。

四、确保 Cloudflare 与 Nginx 配置一致

如果你的应用部署在 Cloudflare 作为 CDN 后端，除了调整 Nginx 配置外，还需要确保 Cloudflare 的缓存设置与 Nginx 配置一致。下面是几项关键设置：

Edge Cache TTL：确保 index.html 的 TTL 设置为 0 秒，这样每次请求都会从源站获取最新的 HTML 文件。
Cache Everything：可以对 JS、CSS 文件启用此规则，并设置较长的 TTL（例如 1 年），避免缓存过期。
清除缓存：通过 Cloudflare 的 Purge Cache 功能，自动清除过期的缓存，确保用户始终访问到最新的资源。

五、总结

Web 应用的缓存问题看似复杂，但其实有迹可循。核心问题在于 HTTP 响应头的缓存策略比 HTML 的 meta 标签更具权威性。通过在 Nginx 层面精细化配置缓存策略，确保 index.html 不缓存，而带有哈希值的静态资源可以永久缓存，我们就能确保每次更新后用户能够无感知地看到最新版本，避免手动清缓存的麻烦。

现在，检查一下你的 Nginx 配置和 Cloudflare 设置，确保它们紧密配合，让每次发布都变得轻松顺畅。