那份没更新的价格表，其实存在客户自己的硬盘上

那张图没变，是因为它压根没从服务器上下来

产品价格表换了新版，图片传上去了，页面一刷新还是旧价——这个场面几乎每月都要碰上一次。第一反应往往是文件没传对、传错目录，或者服务器出了岔子。真要确认，只需要在客户那台电脑上按 F12 打开开发者工具，切到 Network 面板，重新加载一次页面，找到那张图所在的那一行，看最右边的 Size 列。

如果那一列写的是一个具体的数字，比如 240KB，说明它确实从服务器上重新下来了，那问题在你这边；如果写的是 (disk cache) 或者 (memory cache)，那这次请求根本没出过这台电脑的门，浏览器直接从本机把上一次的那张图翻出来用了。同一张 240KB 的图，走网络那次耗时通常在 150 到 250 毫秒之间，命中本地缓存那次一般是 2 到 5 毫秒——时间列上这个数量级的差别，比 Size 列还醒目。

这两种缓存也不是一回事。内存缓存放在这个标签页占用的内存里，标签页一关就没了；磁盘缓存是实实在在写进硬盘的文件，Windows 上的 Chrome 放在用户目录 AppData\Local\Google\Chrome\User Data\Default\Cache 这一层，浏览器彻底退出、电脑重启，它照样在。所以那句「我让客户关掉浏览器重开一次，还是老的」并不奇怪，重开浏览器只清得掉内存那一份。

max-age 后面那个数字，就是这份文件能活多久的秒数

决定一份文件在本机能躺多久的，是服务器在响应头里写的 Cache-Control。里面最关键的是 max-age，单位是秒：max-age=2592000 就是 30 天，max-age=31536000 就是一年。在这个期限内，浏览器连问都不问服务器一句，直接拿本地那份用——这就是常说的强缓存。所以那张价格表要多久才会自己更新，取决于服务器当初发它的时候写了多大的数。

做网站建设时最常见的一种错配，是全站只写一条规则，比如所有静态文件统统 max-age=3600。这个设置两头都不讨好：图片和字体一小时就要重新下一遍，缓存基本白设；而真出了错要紧急改，又得让访客等满一小时。合理的做法是按文件类型分档写，图片、字体这类几乎不会原地修改的，给一年；不带版本号的样式表和脚本，给七天（604800）；HTML 单独处理，下面第六条会说。

在 nginx 里就是按后缀写几段 location 规则，改完 reload 一次即可，不到十分钟的活儿。改完怎么验证：随便打开一个图片地址，在 Network 面板里看它的 Response Headers，Cache-Control 那一行的数字对上了就算生效，不需要等到明天再看。

no-cache 不是不缓存，no-store 才是

这两个词长得太像，用反的概率相当高。讲人话版本：no-cache 是「存，但每次用之前给服务器打个电话问一声还能不能用」；no-store 才是「一个字节都不许留在本地」。

把 no-store 误加在样式表和脚本上，后果是每次翻页都要重新下载那 80KB 的 CSS，回头客的体验和第一次来的人完全一样，缓存这件事等于没做。反过来，真正该用 no-store 的地方却经常漏掉：后台管理页面、带手机号的询盘列表、订单详情页这几类。它们如果被写进磁盘缓存，在共用电脑上退出登录之后，下一个人按几下后退键，仍然可能把上一个人看过的那一屏客户信息翻出来。这不是理论风险，是网站建设验收时值得单独拉出来点一遍的一项。

判断标准可以简单粗暴一点：页面内容是不是因人而异。因人而异的（登录后才能看的、带个人信息的）用 no-store；对所有人都一样的（图片、样式、公开的产品页）不要用。

那个 304 响应只有两三百字节，但一样要跑一个来回

强缓存到期之后，浏览器不会闷头重下，而是先问一句：我手上这份还能用吗。问的方式是带上两个标记——上次服务器给的 ETag（内容指纹）和 Last-Modified（最后修改时间）。服务器一比对，没变就回一个 304，变了才回 200 加新内容。

304 这个响应确实很省流量，它不带正文，整个报文通常只有两三百字节。但省流量不等于省时间：它是一次完完整整的网络往返，国内跨运营商的往返时延一般在 30 到 80 毫秒。一个页面上散着二十多个小图标，每个都乖乖走 304，Network 面板看上去一片绿、传输量几乎为零，实际串起来仍然要吃掉 0.6 到 1.2 秒。

所以协商缓存是兜底方案，不是目标。凡是能靠改文件名做到内容一变 URL 就变的资源，都应该直接给一年强缓存，让浏览器连这一句都不用问。

把指纹写进文件名，比反复调 max-age 省事得多

给缓存加版本，常见两种写法：一种是在地址后面挂参数，style.css?v=20260810；另一种是把内容哈希写进文件名本身，style.a3f9c2e1.css。看起来效果一样，实际差别不小。

查询字符串那种写法有个老毛病：部分中间节点和一些老的代理配置不把问号后面的内容算进缓存键，你把 v 值改了，它认为还是同一个文件，照旧返回旧的。改文件名就没有这个歧义——内容变一个字节，哈希就变，URL 就是一个全新的地址，任何一层缓存都没有它的旧副本，只能老老实实回源取。

现在的构建工具输出带哈希的文件名基本是默认行为，配置一行就够。网站建设中如果是纯手工维护的老站，没有构建流程，退而求其次也可以手动改名，比如每次发版把 main-2026a.css 改成 main-2026b.css，同步改掉 HTML 里的引用。麻烦是麻烦一点，但它换来的是可以给这些文件放心地写上一年缓存，而不用在每次改版前后手忙脚乱地调数字。

HTML 那一份缓存久了，等于自己给自己挖坑

上面所有做法都建立在一个前提上：HTML 必须是新的。HTML 是入口清单，它里面写着这次要加载哪几个带指纹的文件。清单是旧的，里面列的自然还是旧文件名，后面配得再漂亮也白搭。

见过给首页 HTML 设 max-age=600 的，理由是减轻服务器压力。实际效果是：文案改完上线，客户在那十分钟里刷新多少次都是旧的，电话已经打过来了。HTML 应该用 no-cache——存是存着，但每次都问一句服务器，没变就回 304（那份 HTML 才十几 KB，问一句的成本极低），变了立刻拿新的。

这套组合拳配齐之后，一次改版上线，老访客的实际下载量是这样的：重新下一份 4KB 左右的 HTML，加上这次真正改动过的那一个脚本文件，其余样式表、图片、字体全部命中本地，一个字节都不用重传。这也是为什么把缓存策略写进网站建设的交付清单，比上线后再一项项排查划算得多。

F5 和 Ctrl+F5 按下去的不是同一件事

三种打开方式，触发的缓存行为完全不同，混着用就会得出互相矛盾的结论。点链接进来或者在地址栏敲回车：完全按 max-age 走，还在有效期内就直接用本地的，一个请求都不发。按 F5 或者点刷新按钮：浏览器会跳过一部分强缓存，对资源发协商请求，这时候 Network 面板里会出现一大片 304。按 Ctrl+F5（Mac 上是 Shift 加刷新）：请求头里带上 Cache-Control: no-cache，所有东西一律重新下载。

知道这个区别，就能解释网站建设过程中几乎天天上演的那句对话——「我这边刷新了是新的啊」。说这话的人多半按的是 Ctrl+F5，而客户按的是 F5，甚至只是关掉页面重新打开。两边看到的本来就是两份东西。

自己验证的时候，稳妥的做法是开一个无痕窗口访问，那里没有历史缓存，最接近新访客的处境。开发者工具里的 Disable cache 勾选框也能用，但要记住它只在开发者工具处于打开状态时才生效，一关掉就恢复原样。

客户说还是老的，让他做三件事就能定位到底卡在哪一层

第一件，让他按一次 Ctrl+F5。如果变新了，那就是纯粹的浏览器缓存，问题范围到此为止，后面按前面几条改文件名或者调 max-age 就行。如果还是老的，往下走。

第二件，让他关掉 Wi-Fi，用手机流量打开同一个地址。换了网络出口，如果内容变新了，说明本地缓存没问题，卡在中间那一层——他所在网络的运营商缓存，或者你自己套的 CDN 没刷新。如果用流量打开还是旧的，那才轮到怀疑服务器上的文件本身。

第三件，让他把 Network 面板里那一行的 Response Headers 截个图，重点看两个字段：age 和 cache-control。age 大于 0，说明这份内容是从某个中间节点拿的，那个数字就是它在节点上已经躺了多少秒。真到了要刷缓存的时候，顺序不能反：先刷 CDN 或者服务端那一层，再去处理浏览器这一层。反过来做，浏览器刚清干净，一转身又从中间节点上把旧的取回来了，前面那一趟等于白跑。