第 4 卷

• 输入具体资源名（如 .js、 .png）：筛选特定类型资源的缓存状态。

用于查看和管理本地缓存数据，验证缓存是否正确存储/更新：

• Cache Storage：查看Service Worker缓存的资源，可手动删除/刷新。

• Local Storage/Session Storage：虽非HTTP缓存，但可查看页面存储的本地数据，辅助判断是

否存在缓存相关的业务数据问题。

• Clear storage：一键清除所有缓存（包括磁盘/内存缓存、Service Worker缓存），方便重新测试

缓存生效流程。

三、调试缓存的核心流程（实战步骤）

1. 打开开发者工具（F12），切换到Network面板，取消勾选「Disable cache」。
2. 首次加载页面：查看所有资源的Size列（应显示文件大小，无from cache），验证Response

Headers中的缓存规则是否正确设置。

1. 二次加载页面：查看静态资源是否显示from disk cache/memory cache（强缓存生效），动态资

源是否返回304（协商缓存生效）。

1. 手动刷新（F5）：验证所有资源是否发起协商缓存请求（携带If-None-Match/If-Modified-

Since）。

1. 强制刷新（Ctrl+F5）：验证所有资源是否均从服务器下载（Size显示文件大小，无缓存标识）。
2. 若缓存未生效：检查Response Headers中的Cache-Control/ETag等字段是否缺失或配置错误（如

max-age设置为0）。

8. 描述浏览器如何处理强缓存和协商缓存的决策过程

浏览器对强缓存和协商缓存的处理是分层递进的决策流程：优先判断强缓存是否生效，若生效则直接复用本地缓存；若强缓存失效，再进入协商缓存流程，向服务器验证资源是否更新，最终决定是复用

缓存还是下载新资源。整个过程由浏览器自动完成，无需开发者干预，核心依据是服务器返回的缓存相关HTTP头。

完整决策流程（步骤拆解）

1. 发起资源请求前：浏览器先检查本地是否存在该资源的缓存副本，同时获取缓存存储的「缓存规

则」（如Cache-Control、Expires、ETag、Last-Modified）。

• 若存在Cache-Control: max-age=xxx：计算资源从服务器返回的时间（响应时间）+ max-age时

长，若当前时间未超过该时间，则强缓存生效；否则失效。

• 若仅存在Expires：对比客户端本地时间与Expires中的绝对时间戳，若本地时间未超过该时间，则

强缓存生效；否则失效。

• 若同时存在Cache-Control和Expires：忽略Expires，以Cache-Control的max-age为准

（HTTP1.1优先于HTTP1.0）。

• 强缓存生效：直接从本地缓存（磁盘/内存）读取资源，流程结束，不发起任何网络请求，状态

码显示200 OK (from disk cache/memory cache)。

• 强缓存失效：进入下一步协商缓存流程。

1. 第二步：发起协商缓存请求

强缓存失效后，浏览器不会直接丢弃本地缓存，而是携带「资源更新标识」向服务器发起「条件请求」，核心目的是验证本地缓存的资源是否仍为最新：

• 若本地缓存存在ETag：请求头携带If-None-Match:「ETag的值」（如If-None-Match:

"abc123def"）。

• 若本地缓存存在Last-Modified：请求头携带If-Modified-Since:「Last-Modified的值」（如If-

Modified-Since: Wed, 01 Jan 2026 08:00:00 GMT）。

• 若同时存在ETag和Last-Modified：优先携带If-None-Match（ETag优先级更高），服务器优先验

证ETag。

1. 第三步：服务器验证资源是否更新

服务器接收条件请求后，根据请求头携带的资源标识，对比服务器端当前资源的标识：

• 验证ETag：对比请求头If-None-Match的值与服务器端资源当前的ETag，若一致则资源未更新；

若不一致则资源已更新。

• 验证Last-Modified：对比请求头If-Modified-Since的值与服务器端资源当前的最后修改时间，若

请求头时间≥服务器时间则资源未更新；否则已更新。

1. 第四步：根据验证结果处理缓存

• ✅ 资源未更新：服务器返回304 Not Modified响应，无资源体，仅返回少量响应头（如Date、

ETag等）。浏览器接收后，复用本地缓存资源，同时更新缓存的“新鲜度”（部分浏览器会重置缓存的有效期，以服务器当前时间重新计算max-age），流程结束。

• ❌ 资源已更新：服务器返回200 OK响应，携带新资源内容和新的缓存规则（新的Cache-

Control、ETag、Last-Modified等）。浏览器接收后，下载新资源并覆盖本地旧缓存，然后使用新资源，流程结束。

特殊决策场景（影响流程的关键因素）

• 资源无缓存规则：服务器未返回任何缓存相关HTTP头，浏览器默认不缓存该资源，每次请求都从

• 设置Cache-Control: no-cache：强制跳过强缓存流程，直接进入协商缓存，每次请求都需向服务

• 设置Cache-Control: no-store：完全禁用缓存，浏览器不存储任何资源副本，每次请求都从服务

器下载新资源，不触发强缓存和协商缓存。

• 手动/强制刷新：手动刷新（F5）强制跳过强缓存，进入协商缓存；强制刷新（Ctrl+F5）禁用所有

缓存，直接下载新资源。

9. 其他缓存相关的问题

除核心缓存机制外，实际开发中还会遇到缓存穿透、缓存雪崩、缓存一致性、CDN缓存协同等问题，这些是面试高频拓展考点，也是生产环境缓存策略设计的关键。

一、缓存穿透（缓存未命中，请求直达服务器）

• 定义：请求的资源既不在浏览器缓存，也不在服务器缓存（如CDN、服务端本地缓存），导致所有

请求都直达源服务器，可能造成服务器压力过大。

• 常见场景：请求不存在的资源（如恶意攻击的无效URL）、新上线的资源（首次请求无任何缓

存）。

• 解决方案：

1. 对无效资源返回默认响应并缓存（如返回空JSON，设置较短的max-age，如60秒），避免重复

请求。

1. 服务端实现资源校验，快速拦截无效请求（如参数合法性校验）。
2. 新资源预热：上线前主动请求资源，生成浏览器/CDN缓存。

二、缓存雪崩（大量缓存同时过期，请求洪峰）

• 定义：大量静态资源的缓存同时过期（如同一时间部署的资源，max-age设置相同），导致二次加

载时所有资源都发起协商缓存或重新下载，形成请求洪峰，压垮源服务器。

• 解决方案：

1. 缓存过期时间“打散”：为不同类型资源设置不同的max-age（如JS设置31536000秒，图片设

置31536000秒但添加随机偏移量，避免同时过期）。

1. 分层缓存：CDN缓存与浏览器缓存设置不同的过期时间（如CDN缓存过期时间比浏览器长1小

时），即使浏览器缓存过期，仍可从CDN获取，避免直达源服务器。

1. 永久缓存+哈希更新：静态资源采用“max-age=31536000 + 哈希命名”，通过文件名变更实现

资源更新，避免缓存过期问题。

三、缓存一致性（本地缓存与服务器资源同步）

• 定义：服务器资源更新后，如何确保浏览器快速丢弃旧缓存、加载新资源，避免用户看到旧内容。