普通刷新与强制刷新：HTTP缓存、Service Worker与CDN

“用户说页面还是老样子是不是缓存没清”这句话在过去几年里我听过不下几十次而十次里有七八次最后都落在一个极简单的动作上——让对方按下 CtrlF5。浏览器刷新与强制刷新的区别几乎是我带新同学时必讲的第一课它看起来只是两个按键的差别实际上牵连着 HTTP 缓存语义、内存与磁盘缓存分层、Service Worker 生命周期、CDN 边缘节点甚至浏览器的往返缓存。很多人把“强制刷新”当成万能钥匙也有人从来不敢用怕“把什么东西刷坏了”。这篇文章就是把这件事彻底讲透两种刷新在协议层到底发出了什么、缓存链路上能穿透到哪一层、不同内核和终端的实际行为差异以及作为开发者我们应该怎样设计缓存策略让用户压根不需要学会这组快捷键。无论你是刚接触前端的同学还是已经在线上事故里摸爬滚打过的老兵下面这些内容都能直接拿去用。1. 两种刷新差的不只是一个按键1.1 一个反复出现的现场为什么用户按了刷新还是旧的先还原一个几乎每个团队都遇到过的场景。某个后台系统改了一版样式静态资源重新发布上线开发者自己在本地验证没问题通知使用方“刷新一下就好”。结果对方回了一句还是老样子。于是对话开始拉扯——你是不是没刷新我按了 F5 了。你试试 CtrlF5好了。整个过程里双方都不知道刚才那一下到底发生了什么只知道“玄学地好了”。这种靠口口相传维持的排查方式本质上掩盖了一个事实F5 和 CtrlF5 发送出去的请求在协议层面是完全不同的两个东西。我在某项目里做过一次小小的统计把线上“发布后反馈未生效”的工单按原因归类结果很有意思真正因为浏览器缓存没更新导致的比例大约占四成剩下六成里一部分是 CDN 边缘节点还没回源一部分是 Service Worker 拿着旧版本不放还有一部分是页面本身就没重新请求——用户只是切了个标签页回来或者点了后退浏览器直接从内存里把快照弹了出来一个字节的网络请求都没发。也就是说当我们让用户“刷新”的时候用户的动作、浏览器的实现、服务器的响应三者之间存在大量认知错位。所以理解这件事的第一步是把“刷新”这个词拆开。用户嘴里的“刷新”可能是按 F5可能是点地址栏回车可能是下拉页面可能是关掉标签页重开可能是手机端下拉刷新触发的一次 WebView 重载——这五种操作在缓存处理上的行为各不相同。而我们嘴里的“强制刷新”在不同内核、不同版本上实现细节也有出入。把这些差异理清楚后面的所有排查才有依据。注意把“用户没刷新”当成默认结论是排查效率最低的一种做法。先确认现象复现路径再判断缓存层级顺序反过来会浪费大量时间。1.2 刷新时浏览器到底发生了什么从技术上说一次普通刷新F5、CtrlR、CmdR或者点击刷新按钮触发的是导航流程中的“重新加载”。浏览器会重新走一遍主文档的加载解析 URL、查找缓存、建立连接、接收响应、解析 HTML、构建 DOM、加载子资源。听起来像是“全量重来”但关键在于其中“查找缓存”这一步并没有被跳过。具体一点普通刷新时浏览器对主文档的处理策略是仍然允许使用本地缓存但如果缓存副本带有效期它会倾向于做一次重新校验。换成人话就是——它会问服务器一句“我手里这份还是最新的吗”。服务器如果回答“是”返回一个没有响应体的状态码浏览器就把本地那份拿出来用服务器如果回答“不是”才返回新内容。问题恰恰出在“它会问”这个前提上如果缓存策略是“在有效期内不需要问”那浏览器连问都不会问直接用旧的。而强制刷新CtrlF5、ShiftF5、ShiftCmdR或者长按刷新按钮选择“硬性重新加载”走的是另一条路径它明确告诉浏览器“这次别用本地那份也别问直接给我新的”。浏览器会给这次导航请求打上绕过缓存的标记请求头里带上相应的指令并且不再附带条件校验字段。服务器收到之后正常情况下只能返回一份全新的完整响应。子资源同理页面里引用的脚本、样式、图片在这一轮里也会尽量重新下载而不是从本地直接取。这里有个容易被忽略的细节强制刷新绕过的是“缓存”不是“存储”。Cookie、localStorage、sessionStorage、IndexedDB 这些东西一个都不会被清掉。有些人误以为 CtrlF5 等于“恢复出厂设置”其实完全不是。它只是让这一轮网络请求不吃缓存而已页面里的登录态、主题设置、草稿数据统统原封不动。这个认知差在很多“我强制刷新了怎么还是登录状态”的疑问里反复出现。1.3 请求头层面的硬对照要真正把两者区分开最直接的办法是打开开发者工具看同一个页面在两种刷新方式下主文档请求头的差异。下面这张表是我在多个项目里反复验证过的对照字段含义在各内核上基本一致个别差异我会在后面单独说明。对比项普通刷新F5 / CmdR强制刷新CtrlF5 / ShiftCmdR是否允许使用本地缓存允许但倾向于重新校验不允许直接走网络Cache-Control请求头通常会附加max-age0附加no-cachePragma请求头一般不带常带no-cache兼容旧代理条件校验字段可能携带If-None-Match/If-Modified-Since通常不携带服务端典型响应304 Not Modified 或 200200完整响应体子资源处理未过期的直接从缓存取尽量重新获取是否清除 Cookie / 本地存储否否是否绕过 Service Worker否较新内核会临时绕过看到max-age0这个指令很多人会误读成“不缓存”。实际上它的语义是“这份副本的剩余有效期是 0 秒”也就是立刻过期立刻需要用条件请求去校验。它和no-cache的效果在多数场景下接近但严格来说no-cache更明确地表达“不要直接用先校验”。而no-store才是真正的“不要存”。这三个指令经常被混为一谈配置缓存头时写错一个字母排查起来能耗掉半天。还有一点值得强调强制刷新在请求头里带Pragma: no-cache是历史遗留的兼容做法为的是对付那些只认 HTTP/1.0 语义的老中间层。现代浏览器发这个头更多是保险你不能指望所有代理和网关都完整支持Cache-Control。这也是为什么在配置响应头时一些老项目仍然会同时写Pragma和Expires属于“向后兼容的冗余”不算错但要知道它是冗余。2. 缓存链路拆解刷新动作究竟能穿透几层2.1 强缓存、协商缓存与 immutable 这个例外要判断一次强制刷新到底有没有用得先知道一个请求从浏览器发出之前会经过哪些缓存判定。标准流程大致是这样先看有没有缓存副本如果有判断它是否“新鲜”新鲜就直接用这叫强缓存命中不新鲜就发起条件请求去校验这叫协商缓存。校验通过返回 304浏览器复用本地副本校验不通过返回 200浏览器用新内容替换。决定“新鲜”与否的核心字段是响应头里的Cache-Control常见指令我整理成了下面这张表配置缓存策略时基本就是在这几个词里做选择指令含义普通刷新时的表现max-age秒数副本在指定秒数内视为新鲜未过期则可能直接使用no-cache可存储但每次使用前必须校验会发起条件请求no-store完全不存储每次都完整请求must-revalidate过期后必须校验不许用陈旧副本过期后发起校验immutable有效期内绝不校验见下方说明private/public限定可缓存的范围影响中间层行为immutable是这里最值得单独拎出来讲的一个。它的设计初衷是给那些文件名带内容指纹的静态资源用文件名变了内容必然变所以只要文件还在有效期内浏览器就完全没必要去问服务器。方案本身很优雅但它带来一个副作用——对于标了immutable的资源普通刷新在很多内核上依然不会发起校验请求直接拿本地副本。也就是说用户按了 F5看着页面转了一圈实际上那个带immutable的脚本根本没重新请求过。我在一个内容型项目里就踩过这个坑。当时为了让静态资源加载更快给所有带 hash 的文件统一加了max-age31536000, immutable。上线后发现一个问题某个文件的内容改了但文件名生成逻辑出了岔子hash 没变。结果就是强制刷新能好普通刷新永远好不了而用户不会强制刷新。这件事之后我定了一条规矩immutable只能用在文件名确实由内容决定、且构建流程有校验的场景否则宁可退一步用max-age加常规校验。注意immutable不是加速按钮它是一份“我保证内容与文件名严格绑定”的契约。构建链路里任何一环可能破坏这个契约就别用。2.2 内存缓存、磁盘缓存与往返缓存开发者工具的 Network 面板里请求的 Size 列会显示(from memory cache)或者(from disk cache)这两个东西经常被统称为“浏览器缓存”但它们的生命周期完全不同。内存缓存活在渲染进程的内存里页面一关或者标签页被回收就没了通常用于本次会话中刚加载过的资源命中速度极快磁盘缓存落在硬盘上跨会话存活受 HTTP 缓存头控制容量大但读取慢一些。理解这个分层有什么用它能解释一类特别迷惑的现象同一个资源在页面里点来点去的时候是从内存缓存取的怎么刷都不变关掉标签页重开就变成磁盘缓存或者重新请求了突然就对了。我曾经遇到过一个反馈说“某个按钮的图标只有重启浏览器才会更新”最后定位到就是内存缓存——那张图在这次会话里被强引用着普通刷新根本没有触发重新请求而强制刷新确实能解决但用户不知道要这么做。比这两个更隐蔽的是往返缓存也就是前进后退时浏览器保存的整页快照。它连请求都不发直接把离开时的页面状态包括滚动位置、表单内容、JS 运行状态原样恢复。所以“用户说点返回之后页面还是旧的”很多时候根本不是缓存问题而是往返缓存生效了。这种场景下F5 有用CtrlF5 也有用但用户做的是“返回”一个都没用上。处理办法通常是在页面的可见性变化事件里做数据刷新或者监听pageshow事件判断是否来自往返缓存而不是指望用户去按快捷键。这三层的关系可以用一句话概括内存缓存和磁盘缓存受 HTTP 头控制往返缓存不受强制刷新能穿透前两者也能让往返缓存失效但对第三层之外的东西无能为力。这个边界划清楚排查时才不会南辕北辙。2.3 Service Worker 与 CDN 这两层“刷不掉”的缓存如果说浏览器缓存还在“刷新能解决”的范畴内那 Service Worker 和 CDN 就是两个让强制刷新兴叹的层级。Service Worker 本质上是页面和网络之间的一个可编程代理。它自己维护一份缓存存储拦截页面的请求决定是从自己的缓存里返回还是走网络还是搞个“先返回缓存再后台更新”的策略。关键在于它的缓存不归 HTTP 缓存头管是脚本逻辑说了算。你改完代码发布上线用户那边的 Service Worker 可能还跑着几个月前注册的版本拦截逻辑还是老一套于是页面上永远是旧内容。这时候用户按 CtrlF5在较新的内核上确实有可能临时绕过 Service Worker 直接走网络但这是浏览器的特殊行为不是稳定保证而且绕过的只是“这一次”用户下次正常打开还是老样子。真正要解决得靠更新流程页面里调用注册对象的更新接口主动检查监听更新事件发现新版本候选用“跳过等待”让它立刻接管再配合客户的接管事件做一次页面重载。这套流程我在好几个项目里落地过配置得当的话用户从打开页面到用上新版本中间只需要一次自动重载完全无感。CDN 的情况类似但更靠后。用户强制刷新浏览器确实发了新请求但如果请求打到的边缘节点上还挂着一份老副本节点不会回源直接把它返回给你。这时候用户会觉得“强制刷新也没用”而实际上他清的是自己这一端的缓存清不掉服务端那一端。这类问题的定位特征很明显换个网络环境、换个设备访问就正常了或者过了一段时间自己好了。解决办法是发布流程里带上缓存刷新动作或者给入口文件配置较短的缓存时间并配合内容指纹让边缘节点自然失效。我把这三层的穿透关系整理成一句话方便记忆强制刷新能穿透浏览器本地缓存能不能穿透 Service Worker 要看内核实现绝对穿透不了 CDN 边缘节点。3. 各端实操怎么刷、怎么验证、怎么复现用户环境3.1 桌面端快捷键与开发者工具的三个选项快捷键这块不同内核和不同系统的组合不太一样我列一张表日常用得上操作目的常见组合普通刷新F5 / CtrlR / CmdR强制刷新绕过缓存CtrlF5 / ShiftF5 / ShiftCmdR仅重载页面框架部分内核支持 Ctrl点击刷新按钮清空缓存并硬性重载长按刷新按钮后选择或开发者工具菜单打开开发者工具F12 / CtrlShiftI / CmdOptionI长按刷新按钮这个交互值得单独说因为它的三个选项经常被混用。第一个是正常重新加载等同于 F5第二个是硬性重新加载等同于 CtrlF5绕过 HTTP 缓存但不清除任何东西第三个是“清空缓存并硬性重新加载”它会把这个站点的 HTTP 缓存整个清掉再重新拉一遍。第三个选项在排查时非常有用但要注意它的作用范围只到 HTTP 缓存Service Worker 的缓存存储、Cookie、本地存储它都不碰。我见过有人以为点这个就等于“把站点数据清空”结果发现登录态还在一脸疑惑。另外还有一个藏得比较深但极其实用的开关开发者工具 Network 面板顶部的“禁用缓存”勾选框。勾上之后只要开发者工具开着所有请求都不走缓存。它的价值在于排查——你可以在不按强制刷新的情况下稳定地观察“每次都是全新请求”时页面的表现从而判断问题到底出在缓存还是出在代码。关掉开发者工具后这个开关就失效了这算是个保护机制避免开发者的调试习惯影响正常浏览。注意排查线上问题时先让用户打开开发者工具并勾选禁用缓存比让他反复按 CtrlF5 更可靠。前者能持续生效后者只有那一下。3.2 用开发者工具确认资源到底来自哪里判断一个资源有没有真正更新最靠谱的办法不是看页面长相而是看 Network 面板里那一行的状态码和 Size 列。我把常见组合和它们对应的含义整理如下状态码与来源标记含义是否表示拿到了新内容200 from disk cache磁盘缓存直接命中没走网络否200 from memory cache内存缓存命中连磁盘都没读否200 实际大小完整响应从服务端返回是304校验通过复用本地副本否200 from service worker被 Service Worker 拦截并返回取决于 SW 逻辑看到from disk cache或者from memory cache就说明这个请求压根没发出去页面用的还是老东西。看到 304说明发出去了但服务端说“你那份还能用”。只有看到带实际响应大小的 200才代表真的拿到了新内容。这三者在面板上一眼能分出来比任何猜测都快。还有一个小技巧右键点击请求列表的表头把Response Headers里的一些字段调出来看尤其是cache-control、etag、age。age这个字段很多人不看它表示这份响应在缓存里已经躺了多久。如果age显示 3600而你配置的max-age是 600那说明这份副本早就该过期了却还在被用大概率是中间层出了问题比如某个代理忽略了缓存头。需要说明的是开发者工具在打开状态下会改变浏览器的部分行为比如面板开着时某些资源不会被预加载或者首次打开时不会命中内存缓存。所以“我开着工具看是好的用户那边就是不行”这种情况是真实存在的不要用开发者工具里的表现直接推翻用户反馈要以实际网络环境下的行为为准。3.3 移动端、内嵌页面与无痕模式的特殊行为移动端的情况比桌面端复杂得多。手机浏览器上的“刷新”通常是下拉手势或者菜单里的重新加载它在缓存处理上更接近桌面端的普通刷新但各内核实现差异很大有些版本会做得更保守有些则更激进。而内嵌在应用里的页面也就是 WebView 场景更是另一套逻辑宿主应用可能自己维护了一份缓存策略甚至在页面加载前就把资源预取了你在前端配的响应头未必是最终生效的那一层。我在一个移动端项目里遇到过典型情况H5 页面在浏览器里打开一切正常放进应用内嵌之后就出现更新延迟。查了半天发现是宿主容器对入口页面做了一层本地缓存且没有遵循页面的缓存头而是按自己的规则定时刷新。这种问题在纯前端层面无解只能推动容器侧调整策略或者在前端加一个版本探测的兜底——页面加载后请求一个不缓存的版本接口如果发现服务端版本号和本地不一致就主动重载一次。这一招虽然笨但非常有效属于跨端场景下的实用兜底。无痕模式常被当成“绝对干净环境”来用这个理解需要修正。无痕模式确实不保留历史记录和本地数据到会话之外但在会话过程中它仍然会正常使用内存缓存和磁盘缓存只是会在会话结束后清理。所以用它来验证“是不是缓存问题”是有效的——关掉窗口重开就等于一份全新环境但用它来验证“这个页面在网络层面有没有缓存”则可能得出错误结论因为会话内的缓存行为跟普通窗口没有本质差别。还有一个特别容易忽略的场景通过应用内分享卡片、扫码、消息推送打开的页面很多容器会复用同一个 WebView 实例做预加载。这时候页面可能在你看到它之前就已经加载好了你看的时候只是把它切到前台一个刷新动作都没有。用户报告“内容不更新”很可能就是他打开的那一次命中了预加载的旧实例。这类问题在有预加载机制的容器里发生频率不低值得在排查清单里单独列一条。4. 工程化实践让“强制刷新”变成兜底手段而不是常规操作4.1 入口与静态资源分开治理的缓存策略如果一套系统需要用户频繁使用 CtrlF5 才能看到新内容那说明缓存的粒度设计有问题而不是用户不会用。我的经验是把所有资源分成两类分别给完全不同的策略入口文件和静态资源。入口文件就是 HTML或者单页应用里那个引导脚本。它的特点是内容会变、文件名不变、必须及时更新。所以它的策略应该是“可以缓存但每次必须校验”对应Cache-Control: no-cache或者退一步用max-age0, must-revalidate。这样浏览器每次都会带着校验字段去问一句没变就返回 304 省流量变了就返回新内容。302 级别的开销可忽略但时效性保住了。静态资源则是脚本、样式、字体、图片这些。它们的特点是通过构建流程可以做到“内容变则文件名变”所以可以给极长的缓存期一年甚至更久让浏览器和 CDN 都放心大胆地存。文件名里的内容指纹就是版本号指纹变了 URL 就变了自然就是新请求。这两条策略组合起来的效果是用户打开页面入口文件一定会校验拿到最新的 HTMLHTML 里引用的资源 URL 如果变了浏览器就当新文件去下载如果没变说明内容确实没变用缓存完全正确。整个链路里没有一处需要用户手动干预。我在几个项目里都是按这个思路落地的上线后“用户反馈没更新”的工单量下降得非常明显。需要提醒的是入口文件不能配长缓存。这一点在实践里被违反的次数远超想象原因往往是运维图省事给整个目录配了一条统一的缓存规则。目录下所有文件吃同一套策略入口文件于是也被缓存了一年用户一年内看到的都是同一个版本。这种配置错误排查起来很隐蔽因为在开发者工具里看到的响应头是“正确”的只是它不该应用于这个文件。4.2 版本探测与更新提示的落地写法即便缓存策略配得再对仍然有一类场景绕不过去用户已经打开了页面然后在页面上停留了很久期间我们发布了新版本。这时候用户看到的还是老页面他也不会主动刷新因为没有任何信号告诉他“有新东西了”。解决办法是在页面里做一个轻量的版本探测。具体做法是定时请求一个明确的、不缓存的版本文件把它里面的版本号和页面加载时记录的版本号做比较不一致就提示用户“有新版本点击更新”或者干脆静默重载。这个接口必须配no-store否则探测本身就被缓存了等于没探测。const CURRENT_VERSION 20240612-1; const CHECK_INTERVAL 5 * 60 * 1000; async function checkVersion() { try { const res await fetch(/version.json, { cache: no-store }); const { version } await res.json(); if (version version ! CURRENT_VERSION) { showUpdateTip(); } } catch (e) { // 探测失败不影响主流程静默忽略 } } setInterval(checkVersion, CHECK_INTERVAL); document.addEventListener(visibilitychange, () { if (document.visibilityState visible) checkVersion(); });这段代码有两个细节值得说。第一除了定时轮询还监听了页面可见性变化。用户切走再切回来的时候立刻探一次比干等五分钟体验好得多也省掉了大量无意义的轮询请求。第二异常被吞掉了。版本探测是个锦上添花的功能它挂了不能影响主业务这是我在生产环境里踩过坑之后的坚持——早期版本里探测接口挂了导致整个页面卡在加载态教训很深刻。如果项目里用了 Service Worker还要补上更新流程注册后监听更新事件发现新版本在等待时主动让它接管接管完成后重载一次页面。这套流程写起来不复杂但漏掉任何一环都会导致“新版本装上了但没生效”。navigator.serviceWorker.register(/sw.js).then((reg) { reg.addEventListener(updatefound, () { const worker reg.installing; worker.addEventListener(statechange, () { if (worker.state installed navigator.serviceWorker.controller) { worker.postMessage({ type: SKIP_WAITING }); } }); }); }); let refreshing false; navigator.serviceWorker.addEventListener(controllerchange, () { if (refreshing) return; refreshing true; location.reload(); });这里refreshing这个标志位是必须的。没有它重载之后可能又触发一次接管形成循环刷新用户会看到页面无限抽搐。我第一次写这段的时候就没加测试环境里页面刷了七八次才停印象极深。4.3 一套可以直接抄的响应头配置清单下面这份配置是通用的起点服务端是常见的反向代理场景字段含义和写法可以平移到其他网关。核心思路就是前面说的入口短缓存加校验静态资源长缓存加指纹。# 入口文件每次校验保证拿到最新引用 location ~* \.(html)$ { add_header Cache-Control no-cache, must-revalidate; add_header Pragma no-cache; expires -1; } # 带内容指纹的静态资源长缓存且不再校验 location ~* \.(js|css|woff2|png|jpg|svg)$ { add_header Cache-Control public, max-age31536000, immutable; } # 版本探测接口绝不缓存 location /version.json { add_header Cache-Control no-store; expires -1; }几条实操经验补充。第一expires -1这个写法是为了兼容那些只看Expires头的旧客户端它等价于把过期时间设成一个过去的时间点。新一代中间层都认Cache-Control但老系统和某些内嵌容器不一定加这一句成本很低。第二静态资源那条规则依赖文件名带指纹这个前提如果构建流程还没做到先把immutable去掉改成max-age3600之类的短周期别硬上。第三配置改完一定要用真实的响应头验证一遍不能只看配置文件——反向代理的规则会互相覆盖写在后面的可能把前面的盖掉这个坑我见过太多次。5. 排查实录高频问题速查与踩坑心得5.1 常见现象与定位路径速查表下面这张表是我这几年攒下来的基本覆盖了“刷新之后还是旧的”这类问题的绝大部分分支。遇到反馈时按顺序过一遍比凭直觉猜要快得多。现象最可能的原因验证方式处理办法强制刷新正常普通刷新无效入口文件被长缓存看入口响应头的cache-control入口改为no-cache两种刷新都无效换设备正常CDN 边缘节点未回源对比不同网络环境的响应头age发布时刷新缓存或缩短 TTL换设备也无效关标签页重开正常内存缓存被强引用关闭重开对比调整资源 URL 指纹点返回后内容陈旧刷新就正常往返缓存恢复快照监听pageshow看persisted页面可见时主动拉数据发布很久仍无更新无痕模式正常Service Worker 未更新开发者工具看 SW 状态补上更新与接管流程某一张图片永远不更新文件名未随内容变化看 URL 是否含指纹修正构建的文件名规则移动端更新延迟桌面正常容器层缓存或预加载实例用不同容器打开对比加版本探测兜底重载表里第七行和第四行是最容易被误判的。第四行的情况很多人会一口咬定是缓存然后让用户清浏览器数据清完发现还是不行因为往返缓存跟浏览器数据没关系。第七行则常常被推到“网络问题”上实际上是容器策略前端怎么调都没用只能加应用层的兜底检测。判断标准很简单如果强制刷新能解决问题在前端缓存链路如果不能问题在更外层。5.2 我踩过的几个坑第一个坑是关于no-cache和no-store的误用。我曾经在一个接口上配了no-store想法是“这个数据绝对不能缓存”。结果发现某些内嵌容器对这个指令的处理是“不写磁盘但保留内存”导致同一会话内还是会命中。后来改成在 URL 上带时间戳参数才彻底解决。这件事告诉我响应头指令的解释权不完全在自己手里跨端场景下要留后手。第二个坑是关于强制刷新的心理依赖。有段时间团队里形成了习惯一有问题就让用户 CtrlF5。短期看问题消失了长期看掩盖了真正的配置错误——因为强制刷新能绕过一切本地缓存任何缓存策略写错都能被它兜住。等到用户量上来问题集中爆发才发现入口文件配了一年的缓存。后来我定了个规矩任何“强制刷新能解决”的问题都要往下追一层找到配置层面的根因不允许以“让他强刷”结案。第三个坑是关于构建产物的指纹生成。有一次构建脚本改动了hash 的计算方式从“文件内容”变成了“文件路径加时间戳”看起来更唯一了实际上每次构建所有文件名都会变。结果是每次发布都会导致用户全量重新下载缓存命中率跌到接近于零静态资源服务器的流量翻了好几倍。排查的时候看 Network 面板满屏都是 200一个缓存命中都没有非常直观。这件事之后我们给构建流程加了一条断言内容未变的文件产物文件名必须保持一致。这条断言拦下过好几次回归。第四个坑比较小但很典型在开发者工具里调试时勾了“禁用缓存”忘了关然后去验证缓存策略得出的结论全是错的。后来养成习惯验证缓存相关行为之前先确认这个勾选框的状态再看一眼有没有装什么会改请求的扩展。听起来很傻但我相信不止我一个人在这上面浪费过时间。回到最初那个问题。浏览器刷新和强制刷新的区别表面上是两个快捷键往下挖是 HTTP 缓存语义和浏览器分层缓存再往下是 Service Worker 和 CDN 的独立生命周期最底层其实是一个产品问题我们有没有把缓存策略设计到用户不需要知道这些的程度。我现在看待这件事的方式是强制刷新是一个诊断工具不是解决方案它最合适的用途是在排查现场快速验证“问题是不是出在缓存层”验证完之后该改的配置一个都不能少。至于普通刷新它是用户最自然的动作我们能做的就是把入口文件的缓存策略配对让这个自然动作每一次都能拿到该拿的东西。