第 3 卷
Code block
1Cache-Control: no-cache, max-age=60# 60秒强缓存，超时后协商 2ETag: "xxx哈希值"
- 效果：短期内重复请求直接读缓存，超时后验证更新，兼顾性能和时效性。
✅ 四、CDN缓存协同优化（生产必备）
- CDN节点配置与源站一致的 Cache-Control 规则，让CDN缓存静态资源，用户从就近CDN节点
获取，降低源站压力，提升加载速度。
- CDN开启缓存刷新功能，静态资源更新后，手动刷新CDN缓存（配合哈希命名，基本无需手动刷
新）。
- CDN设置 Vary: Accept-Encoding，缓存不同编码（gzip/brotli）的资源，避免返回错误编
码的资源。
✅ 五、避坑要点（缓存策略常见问题）
- ❌ 不要给index.html设置长时效强缓存，否则资源更新后无法生效。
- ❌ 不要给动态接口设置强缓存，否则返回过期数据（如用户登录状态）。
- ✅ 优先使用 Cache-Control: max-age，放弃 Expires，避免客户端时间篡改问题。
- ✅ 静态资源必加 ETag，兜底协商缓存，解决 max-age 过期后的资源验证。
- ✅ 移动端/小程序推荐 immutable 指令，避免刷新页面发起不必要的协商请求。
✅ 六、最终缓存策略总结（生产环境标配）
| 资源类型 | 缓存策略 | 核心目标 |
|---|---|---|
| JS/CSS/图片/字体 | 强缓存1年 + immutable + | 极致缓存，哈希更新兜底 |
ETag + 哈希命名
index.html协商缓存（no-cache）+ 保证资源引用最新，复用缓存 ETag
实时动态接口no-store + no-cache数据绝对最新
追加交付物提议
我可以帮你整理浏览器缓存的面试高频考点速记版（纯核心结论，适合考前快速背诵），需要吗？
6. 浏览器缓存如何影响HTTP请求？不同的缓存策略会如何改变请求响
应？
浏览器缓存的核心作用是拦截或优化HTTP请求：通过本地存储已获取的资源，减少无效网络请求、缩短请求响应链路，不同缓存策略会直接改变请求的发起与否、响应内容及状态码，最终影响请求效率
和资源时效性。
一、浏览器缓存对HTTP请求的核心影响
• 拦截请求：强缓存生效时，浏览器直接复用本地缓存，不向服务器发起任何HTTP请求，彻底跳过
网络传输环节。
• 优化请求：协商缓存时，浏览器发起“条件请求”（仅携带资源标识等少量头部信息），服务器仅
验证资源状态，无需返回完整资源体，大幅减少带宽消耗。
• 改变响应逻辑：缓存存在时，服务器可能返回304（资源未更新）而非200（新资源），浏览器需复
用本地缓存完成资源加载。
• 延长资源复用周期：合理的缓存策略可让资源在本地重复使用，减少同一资源的重复下载请求，提
升页面二次加载速度。
二、不同缓存策略对请求响应的具体改变
| 缓存策略 | HTTP请求状态 | 响应状态码 | 响应内容 |
|---|---|---|---|
| 强缓存（max- | 不发起请求 | 200 OK (from cache) | 无服务器响应，直 |
| age/immutable） | 资源 | ||
| 协商缓存（ETag/Last- | 发起条件请求（携带If-None- | 304 Not Modified（未更 | 304无资源体；20 |
| Modified） | Match/If-Modified-Since） | 新）/ 200 OK（已更新） | 源+新缓存规则 |
| 禁用缓存（no-store） | 每次都发起完整请求 | 200 OK | 返回完整新资源， |
| 强制协商（no-cache） | 每次都发起条件请求 | 304 Not Modified / 200 OK | 同协商缓存 |
- 手动刷新（F5）：强制跳过强缓存，对所有资源发起协商缓存请求，即使max-age未过期。
• 强制刷新（Ctrl+F5）：完全禁用缓存，请求头携带Cache-Control: no-cache、Pragma: no-
cache，服务器返回200 OK+新资源，不复用本地缓存。
• 缓存过期且资源更新：协商缓存验证失败，服务器返回200 OK+新资源，浏览器更新本地缓存后使
用。
- 如何使用浏览器的开发者工具来分析和调试缓存行为？
主流浏览器（Chrome/Firefox/Edge）的开发者工具（F12或Ctrl+Shift+I）提供了完整的缓存分析能力，核心通过「Network（网络）」面板查看请求的缓存状态、头部信息，辅助以「Application（应
用）」面板管理缓存，精准定位缓存问题。
一、核心工具：Network（网络）面板
打开面板后，需先配置筛选条件：勾选「Disable cache（禁用缓存）」（调试时按需开启/关闭），刷新页面即可查看所有请求的缓存相关信息，核心关注以下维度：
- 查看缓存状态（Size列）
Size列直接显示请求的缓存来源，是判断缓存是否生效的核心依据：
- from disk cache：从磁盘缓存加载（持久化缓存）。
- from memory cache：从内存缓存加载（临时缓存）。
- 304 Not Modified：协商缓存生效，复用本地缓存。
- 显示具体文件大小（如200KB）：未命中缓存，从服务器下载资源。
- 查看缓存相关HTTP头（Headers标签）
点击任意请求，在「Headers」标签页中查看「Request Headers（请求头）」和「Response Headers（响应头）」，验证缓存规则是否配置正确：
• 响应头：重点查看Cache-Control、Expires、ETag、Last-Modified，确认强缓存/协商缓存规则是
否生效。
• 请求头：协商缓存时，查看是否携带If-None-Match（对应ETag）、If-Modified-Since（对应
Last-Modified）。
- 过滤缓存相关请求（Filter筛选框）
在筛选框输入关键词，快速定位目标请求：
- 输入 200：查看所有成功请求，区分“from cache”和“服务器返回”的200请求。
- 输入 304：仅查看协商缓存生效的请求。
全站分卷索引 · 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属性；同时对敏感操作（如修改密
- • 用户退出登录时清理数据：用户点击退出登录后，前端需清除存储的令牌、权限信息等，同时调用
- • 敏感操作二次验证：对核心敏感操作（如修改密码、绑定手机号、大额转账），添加验证码、短信
- 四、常见问题与避坑要点
- • ❌ 仅依赖前端权限控制：后端必须对所有敏感接口进行权限验证，前端权限控制仅为用户体验优