第 1 卷
浏览器缓存核心面试题全解析
浏览器缓存核心面试题(全解析)
1. 浏览器缓存的工作原理
浏览器缓存是浏览器对已请求过的资源进行本地存储,当再次请求该资源时,优先从本地读取而非重新从服务器下载,以此减少网络请求、降低服务器压力、提升页面加载速度的机制。
完整工作流程
- 首次请求:浏览器向服务器发起请求 → 服务器返回资源+缓存相关HTTP响应头 → 浏览器下载资
源,同时将资源内容+缓存规则存入本地缓存(磁盘/内存)。
- 再次请求:浏览器先判断本地是否有该资源的缓存,且缓存是否有效:
◦ ✅ 缓存有效:直接读取本地缓存(强缓存),不发起网络请求,状态码 200 OK (from
disk cache/memory cache)。
◦ ❌ 缓存失效:发起条件请求到服务器,服务器根据资源标识判断资源是否更新:
▪ 资源未更新:返回 304 Not Modified,无资源体,浏览器复用本地缓存(协商缓
存)。
- 资源已更新:返回 200 OK +新资源,浏览器更新本地缓存后使用。
缓存存储位置(优先级从高到低)
• Memory Cache(内存缓存):速度最快,生命周期随浏览器标签页关闭而消失,存储小体积、高
频使用的资源(如JS/CSS)。
• Disk Cache(磁盘缓存):速度稍慢,持久化存储,关闭浏览器后仍存在,存储大体积、低频使用
的资源(如图片/视频)。
• Service Worker Cache:独立于浏览器的缓存,可自定义缓存规则,支持离线访问(PWA核
心)。
2. HTTP头中与缓存策略相关的字段
HTTP缓存分为响应头(服务器设置,核心)和请求头(浏览器发起条件请求时携带)两类,核心字段如下:
If-Modified-Since、 If-None-Match、 Cache-Control(请求时的缓存指令)
✅ 辅助/禁用缓存字段
Pragma(兼容HTTP1.0,优先级最高)、 no-cache / no-store(Cache-Control子指令)
3. 核心缓存HTTP头字段的作用(Cache-Control/Expires/Last-
Modified/ETag)
🔹 1. Cache-Control(HTTP1.1核心,优先级最高)
作用:精准定义资源的缓存策略,是强缓存的核心字段,支持多指令组合,覆盖Expires的缺陷(时间戳依赖客户端本地时间)。
格式: Cache-Control: [指令1],[指令2]
核心指令(强缓存相关)
• max-age=xxx:最常用,单位秒,表示资源从服务器返回后,在 xxx 秒内缓存有效,浏览器直
接使用本地缓存(强缓存)。
- 示例: Cache-Control: max-age=3600 → 资源1小时内有效。
- public:资源可被浏览器+中间代理服务器缓存(如CDN),默认静态资源为public。
- private:资源仅能被浏览器缓存,代理服务器不可缓存(如用户个人数据接口)。
• immutable:资源在 max-age 有效期内绝对不变,浏览器即使刷新页面也不会发起协商请
求,强制使用强缓存(适合静态资源如图片/字体)。
核心指令(禁用/协商缓存相关)
• no-cache:不是禁用缓存,而是禁用强缓存,每次请求必须发起协商缓存(向服务器验证资源
是否更新)。
• no-store:完全禁用缓存,浏览器不存储资源,每次请求都重新下载(适合敏感数据如支付页
面)。
• must-revalidate:缓存过期后,必须向服务器验证,不可使用过期缓存(防止代理返回过期
资源)。
HTTP1.1的 Cache-Control: max-age 替代,共存时max-age优先级更高。
🔹 3. Last-Modified(HTTP1.0,协商缓存核心)
作用:服务器返回资源的最后修改时间戳(GMT格式),作为资源的更新标识,用于协商缓存。
- 工作流程:
- 首次请求:服务器返回 Last-Modified: Wed, 01 Jan 2026 08:00:00 GMT + 资源。
- 缓存失效后:浏览器发起请求时,携带请求头 If-Modified-Since: [Last-Modified的
值],向服务器验证。
- 服务器判断:对比资源当前最后修改时间与 If-Modified-Since:
- 未修改:返回 304 Not Modified,无资源体。
- 已修改:返回 200 OK +新资源+新的 Last-Modified。
缺陷:
- 精度低:仅到秒级,若资源1秒内多次修改,无法识别。
- 误判:资源内容未变,仅修改文件名称/权限,最后修改时间会更新,导致不必要的重新下载。
🔹 4. ETag(HTTP1.1,协商缓存,优先级高于Last-Modified)
作用:服务器为资源生成的唯一标识(通常是资源内容的哈希值,如MD5/SHA1),内容变则ETag 变,精准标识资源是否更新,解决Last-Modified的缺陷。
- 工作流程:
- 首次请求:服务器返回 ETag: "abc123def" + 资源。
- 缓存失效后:浏览器发起请求时,携带请求头 If-None-Match: [ETag的值],向服务器验
证。
- 服务器判断:对比资源当前ETag与 If-None-Match:
- 一致(未更新):返回 304 Not Modified。
- 不一致(已更新):返回 200 OK +新资源+新的 ETag。
ETag vs Last-Modified
- ✅ ETag优势:精度高(到字节级)、无时间戳依赖、可识别内容未变但属性变更的场景。
• ✅ 共存策略:服务器同时返回ETag和Last-Modified,浏览器优先使用 If-None-Match 发起协
商请求,服务器优先验证ETag。
全站分卷索引 · 10 卷
- 1第 1 卷
- 浏览器缓存核心面试题全解析
- 浏览器缓存核心面试题(全解析)
- 1. 浏览器缓存的工作原理
- 完整工作流程
- ◦ ✅ 缓存有效:直接读取本地缓存(强缓存),不发起网络请求,状态码 200 OK (from
- ◦ ❌ 缓存失效:发起条件请求到服务器,服务器根据资源标识判断资源是否更新:
- ▪ 资源未更新:返回 304 Not Modified,无资源体,浏览器复用本地缓存(协商缓
- 缓存存储位置(优先级从高到低)
- • Memory Cache(内存缓存):速度最快,生命周期随浏览器标签页关闭而消失,存储小体积、高
- • Disk Cache(磁盘缓存):速度稍慢,持久化存储,关闭浏览器后仍存在,存储大体积、低频使用
- • Service Worker Cache:独立于浏览器的缓存,可自定义缓存规则,支持离线访问(PWA核
- 2. HTTP头中与缓存策略相关的字段
- 2第 2 卷
- 4. 强缓存和协商缓存(核心区别+定义)
- ✅ 强缓存(本地缓存直接生效,无网络请求)
- • Cache-Control: max-age=xxx 未过期
- • Expires 时间戳未到(客户端时间未超过该值)
- • 无网络请求,加载速度最快
- • 状态码: 200 OK (from disk cache/memory cache)
- • 核心控制字段: Cache-Control(主)、 Expires(辅)
- ✅ 协商缓存(需与服务器验证,轻量网络请求)
- • 强缓存过期( max-age 到期/ Expires 超时)
- • 手动刷新页面(F5),强制跳过强缓存
- • 资源设置 Cache-Control: no-cache
- • 有网络请求,但仅传输少量头部信息,带宽消耗低
- 3第 3 卷
- ✅ 四、CDN缓存协同优化(生产必备)
- ✅ 五、避坑要点(缓存策略常见问题)
- ✅ 六、最终缓存策略总结(生产环境标配)
- 追加交付物提议
- 6. 浏览器缓存如何影响HTTP请求?不同的缓存策略会如何改变请求响
- 一、浏览器缓存对HTTP请求的核心影响
- • 拦截请求:强缓存生效时,浏览器直接复用本地缓存,不向服务器发起任何HTTP请求,彻底跳过
- • 优化请求:协商缓存时,浏览器发起“条件请求”(仅携带资源标识等少量头部信息),服务器仅
- • 改变响应逻辑:缓存存在时,服务器可能返回304(资源未更新)而非200(新资源),浏览器需复
- • 延长资源复用周期:合理的缓存策略可让资源在本地重复使用,减少同一资源的重复下载请求,提
- 二、不同缓存策略对请求响应的具体改变
- • 强制刷新(Ctrl+F5):完全禁用缓存,请求头携带Cache-Control: no-cache、Pragma: no-
- 4第 4 卷
- • Local Storage/Session Storage:虽非HTTP缓存,但可查看页面存储的本地数据,辅助判断是
- • Clear storage:一键清除所有缓存(包括磁盘/内存缓存、Service Worker缓存),方便重新测试
- 三、调试缓存的核心流程(实战步骤)
- 8. 描述浏览器如何处理强缓存和协商缓存的决策过程
- 完整决策流程(步骤拆解)
- 特殊决策场景(影响流程的关键因素)
- • 资源无缓存规则:服务器未返回任何缓存相关HTTP头,浏览器默认不缓存该资源,每次请求都从
- • 设置Cache-Control: no-cache:强制跳过强缓存流程,直接进入协商缓存,每次请求都需向服务
- • 设置Cache-Control: no-store:完全禁用缓存,浏览器不存储任何资源副本,每次请求都从服务
- • 手动/强制刷新:手动刷新(F5)强制跳过强缓存,进入协商缓存;强制刷新(Ctrl+F5)禁用所有
- 9. 其他缓存相关的问题
- 一、缓存穿透(缓存未命中,请求直达服务器)
- 5第 5 卷
- • 核心解决方案:
- 四、CDN缓存与浏览器缓存的协同
- • 核心原则:CDN缓存作为“中间代理缓存”,应与浏览器缓存规则保持一致,同时承担“就近分
- • 协同策略:
- 五、HTTP1.0与HTTP1.1缓存机制的差异
- • HTTP1.0:仅支持Expires(绝对时间戳)和Pragma: no-cache,依赖客户端本地时间,易出现缓
- • HTTP1.1:新增Cache-Control(支持max-age、public/private等多指令)、ETag,优先级高于
- 一、XSS攻击的三种主要类型
- • 攻击流程:攻击者将恶意脚本注入到目标网站的数据库中(如评论区、用户资料、留言板等可提交
- • 攻击流程:攻击者构造包含恶意脚本的URL → 诱导用户点击该URL → 目标网站将URL中的恶意脚
- • 特点:恶意脚本不存储在服务器,仅存在于攻击URL中,需用户主动点击才能触发,危害相对存储
- • 攻击流程:攻击者构造包含恶意脚本的URL → 用户点击后,目标网站的前端JavaScript代码从URL
- 6第 6 卷
- 11. 解释跨站请求伪造(CSRF)攻击及其防御机制
- 一、CSRF攻击的核心原理与流程
- • 核心前提:用户已登录目标网站,浏览器保存了该网站的身份凭证(如Session Cookie),且
- • 攻击流程:
- 二、CSRF攻击的典型场景
- 三、CSRF的核心防御机制(前端+后端协同)
- • 原理:服务器为每个登录用户生成一个唯一的、随机的CSRF Token(令牌),并将Token存储在
- • 实现流程:
- • 前端注意事项:AJAX请求需主动在请求头中携带Token,避免遗漏;禁止将Token存储在Cookie
- • 原理:HTTP请求头中的Referer字段记录了请求的来源页面URL,Origin字段记录了请求的来源域
- • 实现方式:
- • 局限性:Referer可能被浏览器插件、代理服务器篡改或隐藏(如用户设置隐私模式),无法作为唯
- 7第 7 卷
- • 输入合法性校验:根据业务场景,对用户输入的数据类型、格式、长度进行严格校验,拒绝不符合
- • 特殊字符过滤/转义:对用户输入中的SQL特殊字符(如单引号'、双引号"、分号;、逗号,、星号*、-
- • 对所有用户输入字段设置合理的长度限制(如用户名3-20位、密码6-20位、评论内容0-500字),
- • 目的:缩短攻击者可注入的恶意SQL代码长度,降低攻击成功率(复杂的恶意SQL语句通常需要较
- • 禁止在前端将用户输入拼接到任何类似SQL的字符串中(即使是前端模拟数据展示),避免被攻击
- • 示例:前端搜索功能,禁止将用户输入的关键词直接拼接到类似 SELECT * FROM goods
- • 敏感操作使用POST请求:GET请求的参数会暴露在URL中,易被攻击者篡改和利用;敏感接口
- • 避免在URL中暴露敏感参数:如用户ID、订单ID、数据库表名等敏感信息,不要作为URL参数传递
- • 对用户输入的非法内容,给出明确的错误提示(如“用户名仅允许字⺟、数字、下划线”),引导
- • 避免给出详细的错误信息:如用户登录失败时,提示“用户名或密码错误”,而非“用户名不存
- • 前端向后端传递用户输入时,采用“键值对”的形式传递原始数据(而非拼接后的字符串),让后
- • 示例:登录请求传递 {username: "admin", password: "123456"},而非传递拼接后的
- 8第 8 卷
- 14. 解释同源策略(SOP)及其对Web安全的意义
- 一、同源的定义(三个条件必须同时满足)
- • 协议(Protocol)相同:如都是HTTP或都是HTTPS(http://example.com与
- • 域名(Domain)相同:如example.com与www.example.com不同源(子域名不同),
- • 端口(Port)相同:如http://example.com:80与http://example.com:8080不同源(默认端口可
- 二、同源策略的核心限制范围
- • 不同源的脚本无法访问当前源页面的DOM元素,如通过iframe嵌入的不同源页面,父页面无法获取
- • 示例:攻击者在恶意网站中嵌入银行网站的iframe,由于同源策略限制,恶意脚本无法获取iframe
- • 不同源的脚本无法访问当前源的本地存储数据,包括Cookie、localStorage、sessionStorage、
- • 示例:恶意网站的脚本无法读取用户访问银行网站时存储在localStorage中的用户信息,也无法获
- • 不同源的脚本无法向当前源发起AJAX/Fetch请求(跨域请求),浏览器会拦截该请求,返回CORS
- • 示例:前端项目部署在http://frontend.com,无法直接通过AJAX请求http://backend.com的接口
- 9第 9 卷
- • 场景描述:PWA(渐进式Web应用)等支持离线访问的应用,对离线存储的业务数据(如离线订
- 二、前端加密的核心限制(不可替代后端加密)
- • 前端加密的密钥必须存储在前端代码中(如JS文件)或通过网络传输到前端,攻击者可通过查看源
- • 示例:前端使用RSA加密密码,公钥存储在JS文件中,攻击者可直接获取公钥,无法保证加密的安
- • 前端代码完全暴露在客户端,攻击者可通过修改JS代码篡改加密逻辑(如禁用加密、替换为明文传
- • 示例:攻击者通过浏览器开发者工具修改登录页面的JS代码,绕过密码加密逻辑,直接提交明文密
- • 前端加密依赖浏览器的加密API(如Web Crypto API),若浏览器存在安全漏洞,或用户使用被篡
- • 前端加密仅能保证数据传输过程的安全性,无法保证后端接收数据后的数据存储、处理过程的安全
- • 前端加密(尤其是非对称加密)需要消耗浏览器的CPU资源,可能影响页面性能(如复杂加密逻辑
- • 部分旧浏览器不支持现代加密API(如Web Crypto API),存在兼容性问题,需额外处理降级方
- 三、前端加密的使用原则
- • 前端加密仅作为「补充防护」,核心安全保障必须依赖后端加密(如HTTPS、后端参数验证、数据
- 10第 10 卷
- • 实现方式:使用AJAX请求拦截器,对需要特定权限的接口,前端先验证用户是否拥有该权限,无权
- • 注意:前端接口级权限控制仅为辅助,后端必须对每个敏感接口再次验证用户权限,防止攻击者绕
- 三、前端认证和授权的安全加固措施
- • 使用HTTPS协议:所有认证相关的请求(登录、令牌刷新、敏感接口)必须通过HTTPS传输,防
- • 安全存储令牌:
- • 设置合理的令牌有效期:JWT令牌有效期不宜过长(如2小时),同时实现令牌刷新机制(Refresh
- • 防范XSS攻击窃取令牌:开启CSP(内容安全策略)、对用户输入进行过滤编码、避免使用
- • 防范CSRF攻击:若使用Cookie存储令牌,必须设置SameSite属性;同时对敏感操作(如修改密
- • 用户退出登录时清理数据:用户点击退出登录后,前端需清除存储的令牌、权限信息等,同时调用
- • 敏感操作二次验证:对核心敏感操作(如修改密码、绑定手机号、大额转账),添加验证码、短信
- 四、常见问题与避坑要点
- • ❌ 仅依赖前端权限控制:后端必须对所有敏感接口进行权限验证,前端权限控制仅为用户体验优