嘿，朋友，咱们今天不聊虚的，就聊聊浏览器和服务器之间那场永无止境的“拉扯”。你有没有过这种经历：明明网页就在那儿，点一下图片愣是半天不出来，刷新一下秒开；或者你刚改完代码，发布上去，用户那边还是旧页面，气得你直拍桌子？
这背后，其实是 HTTP 缓存机制在偷偷干活。很多人听到“缓存”俩字就头大，觉得这是网络工程师的事，跟我有什么关系？大错特错！作为开发者，如果你不懂怎么控制浏览器什么时候该去问服务器“嘿，你改了吗”，什么时候该直接懒洋洋地复用本地货，那你的应用要么慢得让人想卸载，要么服务器扛不住被压垮。
今天，我就带你钻进浏览器的请求细节里，把强缓存、协商缓存、Expires 和 Cache-Control 这些看似高深的概念，掰开了、揉碎了，讲得连你家隔壁小明都能听懂。咱们不光讲理论，还要手把手教你怎么写配置、怎么调试、怎么排查那些让你深夜崩溃的“缓存坑”。
一、先搞懂：浏览器为什么要“偷懒”？
想象一下，你是一个每天都要去图书馆借书的人（浏览器），图书馆管理员是服务器。每本书对应一个网页资源，比如一张高清大图、一个 JavaScript 文件、或者一个 CSS 样式表。
如果每次你去借书，都要先给管理员打个电话问：“嘿，这本书还在吗？有没有改版？”管理员又要查数据库、又要核对记录，累得半死。而你呢，也得干等着回复，才能决定去不去拿书。这效率太低了，对吧？
所以，聪明的做法是：
- 强缓存（Strong Cache）：管理员第一次把书给你时，直接在书上贴个标签：“未来 7 天内，别问我，自己看！”这 7 天内，你直接去书架拿书，连电话都不打。这就是强缓存——完全跳过网络请求，直接从本地读。
- 协商缓存（Negotiation Cache）：管理员贴的标签是：“这周你再来问问我，万一我改了呢？”于是，你每次去拿书前，都会先打个电话问一句：“嘿，书有变化吗？”如果管理员说“没变”，你就回来自行拿；如果“变了”，管理员就把新书给你。这就是协商缓存——还是要发网络请求，但只返回状态码 304，不传数据，省流量。
浏览器也是这么想的。缓存的核心目的就两个：减少网络请求次数（省钱、省流量） 和 加快加载速度（提升用户体验）。
但问题来了：谁说了算？怎么设置？什么时候生效？这就引出了我们今天的主角：Expires 和 Cache-Control。
二、双雄争霸：Expires vs Cache-Control
1. Expires：老派的“过期时间”
早在 HTTP/1.0 时代，就有一个叫 Expires 的响应头。它很简单粗暴：服务器在响应里直接告诉浏览器，“这个资源，在 UTC 时间 2024 年 5 月 1 日 12:00:00 之前，你都不用问我，自己存着吧。”
HTTP/1.1 200 OK
Expires: Wed, 01 May 2024 12:00:00 GMT
Cache-Control: no-cache
Content-Type: image/png
听起来不错？但有个致命缺陷：它依赖客户端和服务器的时间是否同步。
如果你的电脑时间错了（比如你爸爸把你的系统时间改成了 1970 年），那浏览器会觉得“哎呀，这资源早就过期了”，于是立刻发请求去问服务器。更麻烦的是，如果服务器时间比客户端快，浏览器可能认为资源还没过期，一直傻乎乎地用旧缓存，哪怕服务器已经更新了资源——这就是著名的“缓存未更新”问题！
2. Cache-Control：现代的“相对时间+指令”
HTTP/1.1 引入了 Cache-Control，它比 Expires 强大得多。首先，它不再依赖绝对时间，而是用相对时间（秒）；其次，它是一组指令，可以精细控制缓存行为。
最常见的指令有：
| 指令 | 含义 |
|---|---|
max-age=31536000 |
资源在 31536000 秒（1 年）内有效，浏览器可直接使用缓存，不发请求 |
no-cache |
必须向服务器验证（发起协商缓存请求），但不能用旧缓存直接渲染 |
no-store |
完全禁止缓存，每次都要从服务器重新获取 |
public |
任何缓存（浏览器、CDN、代理服务器）都可以缓存 |
private |
只有浏览器可以缓存，CDN 或代理服务器不能缓存 |
must-revalidate |
过了 max-age 后，必须向服务器验证，不能擅自使用过期缓存 |
HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, must-revalidate
Content-Type: image/png
这段配置的意思是：这个 PNG 图片，任何地方都可以缓存，1 年内完全免问服务器（强缓存）。但 1 年后，浏览器必须先去问服务器“你变了吗？”，不能偷懒直接用旧的。
3. 谁说了算？优先级高下
当 Expires 和 Cache-Control 同时存在时，Cache-Control 的优先级更高。这是 RFC 标准规定的，所以如果你发现设置了 Expires 但没生效，检查一下是不是被 Cache-Control 覆盖了。
三、实战场景：强缓存 vs 协商缓存，到底怎么选？
光讲概念不够，咱们得来点真实的业务场景。
场景一：静态资源（图片、CSS、JS）—— 强缓存为主
假设你的网站有一个Logo图片 logo.png，它永远不会变。你会怎么设置缓存？
错误做法：设置 no-cache，导致每次打开网页都要发请求问服务器“Logo 有变吗？”，服务器回复 304，白白浪费一次网络往返。
正确做法：
Cache-Control: public, max-age=31536000
或者，更现代的做法是使用文件名哈希，比如 logo.a1b2c3d4.png，这样只要文件内容一变，文件名就变，浏览器会当成新资源重新请求，而不需要担心缓存问题。这时候，你可以放心设置长期强缓存：
Cache-Control: public, max-age=31536000, immutable
注意 immutable 指令：它告诉浏览器，这个资源在 max-age 内，即使页面重新加载，也不需要再次验证。这在现代浏览器（Chrome 56+、Firefox 46+）中非常有用，能进一步减少不必要的请求。
场景二：动态 HTML 页面—— 协商缓存或无缓存
首页 HTML 通常是动态生成的，包含用户信息、实时数据等。你希望用户看到最新内容，但又不希望每次刷新都从服务器拉取整个页面（那样太慢）。
最佳实践：设置 no-cache 或较短的 max-age。
Cache-Control: no-cache
或
Cache-Control: private, max-age=60, must-revalidate
意思是：最多缓存 60 秒，60 秒内如果用户刷新，浏览器会发请求问服务器“页面有变化吗？”，服务器如果没改，返回 304 和空 body，浏览器直接用旧页面渲染；如果改了，返回 200 和新内容。
场景三：敏感数据（用户信息、支付页面）—— 禁止缓存
这些信息绝对不能缓存，否则会有安全风险。
Cache-Control: no-store, no-cache, must-revalidate
加上 Pragma: no-cache（兼容 HTTP/1.0 的老浏览器）。
四、代码实战：如何在 Nginx、Apache 和 Node.js 中设置缓存？
光说不练假把式。下面我给你三个常见服务器配置的例子，你可以根据自己的技术栈直接抄作业。
1. Nginx：最流行的 Web 服务器
Nginx 的配置非常直观。假设你有一个静态资源目录 /static/，里面放着 CSS、JS 和图片。
server {
listen 80;
server_name example.com;
# 静态资源：长期强缓存
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
root /var/www/html;
expires 1y; # 等价于 Cache-Control: max-age=31536000
add_header Cache-Control "public, immutable";
}
# HTML 页面：协商缓存
location ~* \.html$ {
root /var/www/html;
add_header Cache-Control "no-cache, must-revalidate";
}
# API 接口：通常不缓存
location /api/ {
proxy_pass http://backend;
add_header Cache-Control "no-store, no-cache";
}
}
注意：expires 1y 是 Nginx 的快捷语法，最终会转换成 Cache-Control: max-age=31536000 和 Expires 两个头。但为了明确，我建议显式添加 Cache-Control，因为 expires 指令在一些边缘情况下可能不如 Cache-Control 可靠。
2. Apache：老当益壮
Apache 用 .htaccess 或主配置文件来设置。
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
# HTML 页面：不缓存或协商缓存
ExpiresByType text/html "access plus 0 seconds"
Header set Cache-Control "no-cache, must-revalidate"
</IfModule>
这里用到了 mod_expires 模块，它负责生成 Expires 头。同时，我们用 Header set 显式设置 Cache-Control，确保兼容性。
3. Node.js + Express：全栈开发者的日常
如果你是前端转全栈，或者用 Node.js 做 API 服务，Express 是个不错的选择。
const express = require('express');
const app = express();
// 静态文件服务
app.use(express.static('public', {
maxAge: '1y', // 强缓存 1 年
etag: true, // 启用 ETag（协商缓存的一部分）
lastModified: true // 启用 Last-Modified（协商缓存的一部分）
}));
// 动态路由：首页
app.get('/', (req, res) => {
res.set('Cache-Control', 'no-cache, must-revalidate');
res.send('Hello, world!');
});
// API 路由
app.get('/api/user', (req, res) => {
res.set('Cache-Control', 'no-store');
res.json({ name: 'Alice' });
});
app.listen(3000, () => console.log('Server running on port 3000'));
注意：express.static 的 maxAge 选项直接对应 Cache-Control: max-age=<seconds>。对于动态内容，我们手动设置 Cache-Control 头。
五、调试神器：如何用浏览器开发者工具排查缓存问题？
配置写好了，但浏览器到底有没有按你的预期缓存？这时候，Chrome 开发者工具（DevTools）就是你的救命稻草。
步骤 1：打开 Network 面板
按 F12，切换到 Network 标签。勾选 Disable cache 旁边的复选框（默认是未勾选的，即缓存启用）。
步骤 2：观察请求的 Status 和 Type
刷新页面，你会看到一系列请求。重点看 Status 列：
- 200 OK：从服务器下载了资源。如果
Size列显示(memory cache)或(disk cache)，说明是强缓存命中，但注意，从内存缓存读取时，Status 仍是 200，但不会有网络流量。 - 304 Not Modified：协商缓存命中。浏览器发了请求，服务器说“没变”，返回空 body。
- 200 OK (from disk cache)：从磁盘缓存读取，强缓存。
步骤 3：点击请求，查看 Response Headers
随便点一个请求，在右侧面板找到 Response Headers。你会看到类似这样的内容：
cache-control: public, max-age=31536000
expires: Thu, 01 May 2025 10:00:00 GMT
这就是服务器返回的缓存指令。如果和你预期的不一致，说明配置出错了。
步骤 4：强制刷新 vs 普通刷新
- F5 或 Ctrl+R：普通刷新。如果强缓存未过期，直接从缓存读取，不发请求。
- Ctrl+Shift+R 或 Cmd+Shift+R：硬刷新（Empty Cache and Hard Reload）。清空缓存，强制从服务器重新下载所有资源。这用于测试配置是否正确。
- 右键点击 Network 面板 → Clear browser cache：也可以手动清空。
常见坑点排查
坑点 1：改了服务器配置，但浏览器还是用旧缓存
原因：max-age 还没过期，浏览器继续用强缓存。
解决：硬刷新（Ctrl+Shift+R）测试。如果硬刷新后能看到新的 Cache-Control 头，说明配置生效了，只是缓存周期长。
坑点 2：协商缓存一直返回 200，而不是 304
原因：服务器没有启用 ETag 或 Last-Modified，或者浏览器认为资源已过期。
解决：检查服务器配置，确保启用 ETag。在 Node.js 中，express.static 默认启用；在 Nginx 中，默认也启用。如果禁用后，浏览器会直接重新下载。
坑点 3：移动端缓存和桌面端不一致
原因：不同浏览器对缓存策略的实现可能有细微差异。 解决：用 Chrome DevTools 的 Device Toolbar（F12 旁边有个手机图标），模拟移动端浏览器测试。
六、进阶：ETag 和 Last-Modified，协商缓存的双璧
刚才我们说了协商缓存会返回 304，但浏览器是怎么知道资源有没有变的呢？靠两个东西：ETag 和 Last-Modified。
Last-Modified：基于时间
服务器在响应里加一个 Last-Modified 头，告诉浏览器“这个资源最后修改时间是 2024-05-01 12:00:00 GMT”。
下次浏览器再请求时，会在请求头里带上 If-Modified-Since: 2024-05-01 12:00:00 GMT。
服务器比较这个时间和当前修改时间：
- 如果相同（或更晚），返回 304。
- 如果不同，返回 200 和新内容。
问题：时间精度只有秒级。如果资源在 1 秒内改了两次，Last-Modified 可能检测不到。而且，有些服务器时间同步不准，也会导致误判。
ETag：基于内容指纹
ETag 是服务器生成的一个唯一标识符，通常是资源内容的哈希值（比如 MD5 或 CRC32）。
服务器响应：
ETag: "686897696a7c876b7e"
浏览器请求时：
If-None-Match: "686897696a7c876b7e"
服务器比较 ETag：
- 如果相同，返回 304。
- 如果不同，返回 200 和新内容。
ETag 更精确，因为它是基于内容生成的。但它的缺点是：服务器需要计算哈希，有一定的性能开销。而且，如果资源分布在不同服务器（比如 CDN 集群），每个服务器生成的 ETag 可能不同，导致协商缓存失效。
最佳实践：两者都用
现代服务器通常同时返回 ETag 和 Last-Modified。浏览器优先使用 ETag（因为更精确），如果 ETag 缺失，再回退到 Last-Modified。
在 Nginx 中，默认启用两者：
etag on;
在 Node.js Express 中，express.static 默认也启用。
七、真实案例：一个因缓存导致的线上事故
去年，我公司有个项目出了个诡异的问题：用户反馈登录后还是看到未登录的首页。我们查了很久，最后发现是首页 HTML 被强缓存了。
当时配置如下：
location ~* \.html$ {
expires 7d;
}
意思是，HTML 页面缓存 7 天。但问题是，首页是动态的，不同用户登录状态不同。当用户登录后，第一次访问首页，浏览器缓存了未登录状态的首页。接下来 7 天内，即使用户重新打开浏览器，看到的还是旧的未登录首页。
解决方案：把 HTML 页面的缓存改为 no-cache。
location ~* \.html$ {
add_header Cache-Control "no-cache, must-revalidate";
}
这次事故让我们深刻认识到：缓存策略必须和资源的动态性匹配。动态内容绝对不能强缓存，哪怕是用协商缓存，也要确保服务器能正确识别内容变化。
八、给小白的总结：一张图看懂缓存流程
最后，我用一个简单的流程图，帮你把整个过程串起来。
”` 用户访问网页
|
v
浏览器检查本地缓存
|
+-- 有缓存且未过期？ --> 直接用（强缓存，不发请求）
|
+-- 无缓存或已过期？ --> 发