网页更新后浏览器还在显示旧版详解HTTP缓存机制与服务器缓存策略实战排查

做前端的同学大概都遇到过这种抓狂时刻——明明代码已经部署到服务器了，刷新页面却看不到任何变化，甚至F5强制刷新才能看到更新，或者更诡异的是，换了台电脑、用了另一个浏览器，结果表现还不一样。今天咱们就来把这事儿掰开揉碎讲清楚，让你以后遇到缓存问题不再懵圈。

先说一个真实的故事

上周我帮一个朋友排查问题，他的电商网站刚上线了新的活动页面，结果运营那边反馈说用户看不到新内容，客服已经接到几十个投诉了。他急得跳脚，我在现场打开Chrome DevTools，Network面板一开，发现那个js文件请求的响应头里Cache-Control是max-age=31536000，也就是一年的缓存时间。而文件名还是原来的app.js，没有加版本号。

这就是典型的缓存策略没做好，发布新代码的时候没告诉浏览器”我更新了”。后来我们给他加了文件hash名（比如app.a1b2c3d4.js），再配好服务器的缓存头，问题就解决了。这个故事告诉我们，缓存不是坏东西，没配好才是问题。

HTTP缓存到底是啥？为什么要有它？

缓存这东西，本质上是一种用空间换时间的策略。你想啊，如果没有缓存，每次你访问一个网站，浏览器都要把图片、CSS、JS这些资源从头到尾下载一遍。网速慢的时候，那个白屏等待时间能让你怀疑人生。

有了缓存之后，浏览器第一次下载完资源，会把它存在本地硬盘里。下次再访问同一个页面，浏览器就可以直接读本地副本，而不是再发请求去服务器下载。这样网页加载速度快了，服务器压力小了，用户的流量也省了——一举三得，所以缓存是互联网的基础设施之一。

但问题也在这里：缓存太”忠诚”了。它会一直用旧版本，直到某些条件满足它才去检查更新。如果你更新了服务器上的文件，但缓存条件没满足，浏览器就会继续用旧版，于是你就看到了”网页更新后还在显示旧版”这种诡异现象。

HTTP缓存的两大阵营

HTTP缓存其实分为两个层面，一个是浏览器缓存（客户端缓存），一个是代理服务器缓存（中间层缓存）。我们今天主要讲浏览器缓存，因为大多数情况下问题出在这里。

浏览器缓存又细分为两类：强缓存和协商缓存。这两者的区别很重要，理解了就能明白为什么有时候刷新页面没反应，有时候又会被强制更新。

强缓存：浏览器自己做主

强缓存的意思是：浏览器直接决定用不用缓存，根本不问服务器。如果强缓存还在有效期内，浏览器就直接用本地副本，连请求都不会发到服务器。

控制强缓存的HTTP响应头有两个：Cache-Control 和 Expires。

Cache-Control 是HTTP/1.1引入的，功能更强大也更灵活。它用一些指令来控制缓存行为，最常见的值是：

Cache-Control: max-age=3600

这表示资源在响应后的3600秒（1小时）内是有效的，浏览器在这个时间内直接用它。如果加上public：

Cache-Control: public, max-age=3600

就表示这个资源可以被任何缓存（包括浏览器缓存和CDN缓存）缓存。如果是private：

Cache-Control: private, max-age=3600

就表示只有浏览器可以缓存，中间的代理服务器不能缓存。这个区别很重要，比如一些用户个人信息页面，你可能不希望被CDN缓存，这时候就用private。

Expires 是HTTP/1.0的产物，它用具体的时间戳来表示过期时间：

Expires: Wed, 21 Oct 2025 07:28:00 GMT

它的缺点是比较死板，而且依赖于客户端和服务器的时间是否同步。如果客户端时间不对，整个缓存策略就乱了。所以现代项目基本都用Cache-Control，Expires可以作为兼容旧浏览器的备选。

当两个都设置了的时候，Cache-Control 的优先级更高。

协商缓存：浏览器去问问服务器

如果强缓存过期了，浏览器不会直接放弃，而是会发起一个请求去服务器问一句：”我本地有这个资源的缓存，服务器上有没有更新的版本？”

这就是协商缓存。控制协商缓存的响应头有两个：ETag/If-None-Match 和 Last-Modified/If-Modified-Since。

ETag 是服务器给资源生成的一个唯一标识符，通常是一个hash值：

ETag: "68eeae06cc2e9"

当浏览器再次请求这个资源时，会在请求头里带上：

If-None-Match: "68eeae06cc2e9"

服务器收到请求后，对比一下当前资源的ETag，如果没变就返回304 Not Modified，告诉浏览器”你还是用你本地的吧”；如果变了就返回200 OK和新的资源内容。

Last-Modified 是资源的最后修改时间：

Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT

浏览器请求时带上：

If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT

服务器判断时间有没有变化来决定是否返回新内容。

这两个方案里，ETag更精准一些，因为它基于内容生成，而Last-Modified基于时间戳，如果文件内容改了但时间没变（或者时间被改回去了），Last-Modified就会出错。不过ETag的计算会消耗一点服务器性能。现代项目一般首选ETag。

缓存的工作流程

理解了强缓存和协商缓存，我们来看一个完整的请求流程：

1. 浏览器请求资源
2. 检查强缓存（Cache-Control/Expires）
   - 如果未过期 → 使用本地缓存，状态码200（from cache）
   - 如果已过期 → 进入第3步
3. 发起协商缓存请求（带上ETag或Last-Modified）
4. 服务器判断
   - 资源未变化 → 返回304，浏览器使用本地缓存
   - 资源已变化 → 返回200和新资源，浏览器更新缓存

你可以在Chrome的Network面板里看到这个过程。强缓存命中时，Response Headers里有Cache-Control，Status是200，Size显示(from disk cache)或(from memory cache)。协商缓存命中时，Status是304。

为什么会缓存了旧版？常见原因分析

现在回到你遇到的问题：网页更新了，浏览器却还在显示旧版。我们来逐一排查。

原因一：文件名没变，强缓存还在有效期内

这是最常见的原因。比如你的项目打包后生成的文件名是固定的：

/static/js/app.js
/static/css/main.css
/static/img/logo.png

服务器配置了强缓存，比如max-age=86400（一天）。你更新了代码，重新打包，文件名还是一样。浏览器一看：哦，这个文件我缓存过，而且还在有效期内，直接用本地副本。服务器上那个新版本？根本懒得去问。

解决方案：给文件名加hash。这是现代前端构建工具（Webpack、Vite等）的标配。比如Webpack的output.filename配置：

module.exports = {
  output: {
    filename: 'js/[name].[contenthash:8].js',
    chunkFilename: 'js/[name].[contenthash:8].chunk.js'
  }
};

这样每次内容变化，文件名就会跟着变，比如app.a1b2c3d4.js。旧文件不会被引用，浏览器会请求新文件，自然就能拿到最新版本了。

原因二：只有HTML被缓存了

有时候JS和CSS已经用了hash名，但HTML本身没变。HTML作为入口文件，它引用了那些带hash的资源。如果HTML被强缓存了，用户看到的就是旧的HTML，里面引用的还是旧版的JS和CSS。

排查方法：在Network面板看HTML请求的缓存状态。如果HTML是强缓存命中的（from cache），那就说明问题出在HTML的缓存策略上。

解决方案：HTML文件不应该被长期缓存。它可以配置为协商缓存，或者缓存时间设得很短：

Cache-Control: no-cache

或者用更精确的策略：

Cache-Control: max-age=0, must-revalidate

no-cache不是说不要缓存，而是说缓存前必须先和服务器确认。must-revalidate表示过期后必须验证，不能直接使用过期缓存。

原因三：浏览器按请求URL缓存，但URL没变

即使HTML没被缓存，如果你的资源URL一直没变，比如：

<script src="/static/js/app.js?v=1.0.0"></script>

你更新了代码但忘了改版本号，浏览器还是会用旧缓存。版本号变更很重要：

<script src="/static/js/app.js?v=1.0.1"></script>

新版本号让浏览器认为这是一个新资源，会去服务器重新下载。

不过这种方案不如hash名靠谱，因为你要手动维护版本号。用构建工具自动生成的hash名更省心。

原因四：CDN或代理服务器缓存了旧版

这个问题更隐蔽。你的服务器可能已经更新了，但CDN节点或者反向代理（比如Nginx、CDN服务）还缓存着旧版本。用户请求先到CDN，CDN发现有缓存就直接返回了，根本没去源站拿新版本。

排查方法：在请求头里加Cache-Control: no-cache强制绕过CDN缓存，看看能不能拿到新版本。如果可以，那就是CDN缓存的问题。

解决方案：CDN一般都有缓存刷新功能，在控制台上可以手动清除特定URL的缓存，或者配置更短的TTL（Time To Live）。对于重要更新，清除缓存后再发布是一个好习惯。

原因五：Service Worker缓存了旧版

这是一个比较新的坑。如果你用了PWA（渐进式Web应用）或者Service Worker，它会在后台缓存资源，即使用户刷新页面，也可能从Service Worker缓存里读取旧版本。

排查方法：在Chrome DevTools的Application面板里找到Service Workers，看看有没有注册的SW，以及它缓存了哪些资源。

解决方案：在Service Worker的更新逻辑里，处理版本更新。当新的SW被激活时，清理旧缓存，加载新资源。典型的模式是：

// service-worker.js
const CACHE_NAME = 'my-app-v2'; // 版本号跟项目版本保持一致

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.addAll([
        '/',
        '/index.html',
        '/static/js/app.a1b2c3d4.js',
        '/static/css/main.e5f6g7h8.css'
      ]);
    })
  );
});

self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames
          .filter((name) => name !== CACHE_NAME)
          .map((name) => caches.delete(name))
      );
    })
  );
});

每次发布新版本，改一下CACHE_NAME，旧的缓存就会在activate时被清理掉。

服务器缓存策略怎么配？Nginx实战配置

搞清楚了浏览器缓存的原理，咱们来看看服务器端怎么配。以Nginx为例，这是最常用的Web服务器之一。

基础配置

Nginx里配置缓存主要是用expires指令或者add_header来设置响应头。

对于静态资源（JS、CSS、图片等），我们希望长期缓存：

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # 静态资源长期缓存
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }

    # HTML文件不缓存或短时间缓存
    location ~* \.html$ {
        add_header Cache-Control "no-cache, must-revalidate";
        access_log on;
    }

    # 其他文件
    location / {
        try_files $uri $uri/ /index.html;
    }
}

这里expires 1y表示一年，immutable告诉浏览器这个资源不会变化（前提是文件名带了hash），浏览器可以永久缓存不需要再次验证。

带版本号的路径配置

如果你的资源是按版本目录组织的，比如/v1.2.3/js/app.js，可以这样配：

# 按版本目录的静态资源，长期缓存
location ~* ^/v\d+\.\d+\.\d+/ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

# 其他路径
location / {
    proxy_pass http://backend:3000;
}

动态资源的缓存策略

动态内容（比如API返回的JSON）的缓存策略就比较复杂了，需要根据业务来定。有些数据可以缓存几分钟，有些数据必须实时获取。

# API接口，短时间缓存
location /api/ {
    proxy_pass http://backend:3000;
    add_header Cache-Control "public, max-age=60, s-maxage=60";
    # s-maxage只对CDN/代理缓存有效，私有缓存用max-age
}

# 敏感接口，不缓存
location /api/user/ {
    proxy_pass http://backend:3000;
    add_header Cache-Control "no-cache, no-store, must-revalidate";
    add_header Pragma "no-cache";
    add_header Expires "0";
}

no-store是比no-cache更严格的指令，它表示这个资源不能被任何缓存存储。Pragma: no-cache是HTTP/1.0的兼容写法。

清除特定缓存

有时候你需要清除某个资源的缓存，但不想降低全局的缓存时间。Nginx本身没有直接的”清除缓存”命令，但可以通过修改响应头来实现：

# 紧急更新时，临时降低某个资源的缓存时间
location = /static/js/app.js {
    add_header Cache-Control "max-age=0, must-revalidate";
    try_files $uri =404;
}

或者在发布新版本后，改回长期缓存：

location ~* \.(js|css)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

CDN场景下的缓存配置

如果你用了CDN（比如阿里云CDN、Cloudflare、AWS CloudFront），缓存策略需要在CDN控制台也配一遍。CDN的缓存优先级通常高于源站，所以如果你在CDN控制台把缓存时间设成了7天，即使源站返回了max-age=0，CDN可能还是会缓存7天。

常见的CDN配置思路：

静态资源：设置较长的TTL（比如7天到30天），通过文件名hash来保证更新
HTML：设置较短的TTL（比如1分钟到1小时），或者禁用缓存
API：根据业务需求设置TTL，敏感数据不缓存

以Cloudflare为例，你可以在Dashboard里为不同路径设置不同的缓存规则，也可以用Cache Control HTTP头来精确控制。

实战排查步骤

现在你理论知识够了，来一套完整的排查流程。假设你的网站更新了但用户看到旧版：

第一步：确认问题

先确认问题是真的存在。让同事用不同设备、不同网络环境访问，或者用浏览器的无痕模式打开（无痕模式通常不携带缓存），看是否能看到新版本。如果用无痕模式能看到，那基本就是缓存问题。

第二步：检查请求头

打开DevTools的Network面板，刷新页面，找到关键的资源（HTML、JS、CSS），查看它们的请求头和响应头。

重点关注：

请求头里有没有If-None-Match或If-Modified-Since（协商缓存标志）
响应头里Cache-Control的值是什么
状态码是200还是304
Size显示的是(from disk cache)、(from memory cache)还是正常大小

第三步：分析缓存命中情况

如果在Network面板里看到很多资源都是(from cache)，说明缓存策略生效了。关键是判断：这些缓存是应该命中的（强缓存有效期内），还是不应该命中的（已经过期但被错误地缓存了）。

比如一个带hash的文件，如果文件名变了但还是from cache，那就是CDN或代理缓存的问题。

第四步：强制刷新对比

按Ctrl+F5（Windows/Linux）或Cmd+Shift+R（Mac）强制刷新，绕过强缓存。如果强制刷新后能看到新版本，说明问题出在缓存策略上。

然后再试试Ctrl+Shift+R（某些浏览器是Cmd+Option+R）进行软刷新，只绕过强缓存但不清除协商缓存。

第五步：检查服务器配置

登录服务器，查看Nginx或其他Web服务器的配置文件，确认缓存头是否正确设置。检查是否有地方覆盖了正确的配置。

第六步：检查CDN

如果用了CDN，登录CDN控制台，检查缓存配置和缓存状态。尝试清除相关URL的缓存，看问题是否解决。

第七步：检查Service Worker

如果网站有Service Worker，在DevTools的Application面板里查看。可以尝试 unregister 掉当前的SW，清掉缓存，再重新注册。

第八步：验证修复

修复后，清除浏览器缓存（或者用无痕模式），验证能否正常获取最新版本。同时检查其他用户在不同设备上的表现。

一些进阶技巧

用缓存头做灰度发布

有些团队会利用缓存策略来做灰度发布。比如先给一小部分用户返回不带缓存的动态HTML，里面引用的是新版本的资源；其他用户看到的还是缓存的旧HTML，引用旧资源。等灰度验证没问题后，再全量发布。

预缓存与后台更新模式

对于PWA应用，可以采用”后台更新”模式：先展示缓存的版本，同时在后台请求最新版本并更新缓存。用户下次打开时就能看到新版本。这样既保证了可用性，又实现了自动更新。

// 简单的后台更新示例
navigator.serviceWorker.ready.then((registration) => {
  registration.addEventListener('updatefound', () => {
    const newWorker = registration.installing;
    newWorker.addEventListener('statechange', () => {
      if (newWorker.state === 'activated') {
        // 新版本已激活，可以提示用户刷新
        console.log('新版本已就绪，请刷新页面');
      }
    });
  });
});

监控缓存命中率

缓存配置好不好，不能拍脑袋决定。要监控缓存命中率。如果你的CDN或服务器有缓存命中率的统计，留意这些数据。命中率太低说明缓存策略太激进地禁止了缓存，用户体验差；命中率太高但更新不及时，就是缓存太”忠诚”了。

总结

缓存是个好东西，但它需要被正确地管理。网页更新后显示旧版，99%的情况是缓存策略没配好，而不是代码有什么问题。

记住几个核心原则：

静态资源用hash名+长期强缓存，这是现代前端的标准做法
HTML文件不要长期强缓存，用no-cache或很短的TTL
CDN缓存要单独管理，发布新内容后记得刷新CDN缓存
Service Worker要处理版本更新，不能让旧缓存一直坑人
排查时要系统地检查每一个环节，从浏览器到CDN到源站

下次再遇到缓存问题，别慌。打开DevTools，按照上面的步骤一步步来，基本上都能定位到问题所在。缓存这东西，理解它的行为逻辑之后，其实挺简单的。

网页更新后浏览器还在显示旧版 详解HTTP缓存机制与服务器缓存策略实战排查