第 2 卷
4. 强缓存和协商缓存（核心区别+定义）
浏览器缓存分为强缓存和协商缓存两个层级，是缓存工作的核心逻辑，强缓存优先于协商缓存。
✅ 强缓存（本地缓存直接生效，无网络请求）
定义
浏览器根据服务器返回的 Cache-Control / Expires 规则，判断本地缓存是否在有效期内，有效期内直接使用本地缓存，不向服务器发起任何请求，是性能最优的缓存方式。
触发条件
• Cache-Control: max-age=xxx 未过期
• Expires 时间戳未到（客户端时间未超过该值）
特征
• 无网络请求，加载速度最快
• 状态码： 200 OK (from disk cache/memory cache)
• 核心控制字段： Cache-Control（主）、 Expires（辅）
✅ 协商缓存（需与服务器验证，轻量网络请求）
定义
强缓存失效后，浏览器携带资源更新标识（ETag/Last-Modified）向服务器发起条件请求，服务器验证资源是否更新，决定是否复用本地缓存，仅传输请求头/响应头，无资源体传输。
触发条件
• 强缓存过期（ max-age 到期/ Expires 超时）
• 手动刷新页面（F5），强制跳过强缓存
• 资源设置 Cache-Control: no-cache
特征
• 有网络请求，但仅传输少量头部信息，带宽消耗低
• 资源未更新：返回 304 Not Modified，复用本地缓存
• 资源已更新：返回 200 OK，更新本地缓存
• 核心控制字段： ETag/If-None-Match（主）、 Last-Modified/If-Modified-Since
✅ 强缓存 vs 协商缓存核心区别
| 维度 | 强缓存 | 协商缓存 |
|---|---|---|
| 网络请求 | 无（直接读本地） | 有（仅条件请求，无资源体） |
| 服务器交互 | 无 | 有（验证资源是否更新） |
| 状态码 | 200 (from cache) | 304 Not Modified / 200 OK |
| 性能消耗 | 极低（最优） | 低（仅头部传输） |
| 控制字段 | Cache-Control、Expires | ETag/Last-Modified + 对应 |
请求头
触发时机缓存未过期缓存过期/强制刷新/设置nocache
资源一致性依赖缓存有效期，可能存在过实时验证服务器，资源绝对最期资源新
5. 优化网页加载性能的缓存策略设置（实战最佳实践）
缓存策略的核心原则：静态资源强缓存+协商缓存兜底，动态资源禁用缓存/短时效协商缓存，结合 CDN缓存，最大化减少网络请求，兼顾性能和资源更新时效性。
✅ 一、静态资源（核心优化，占比90%，如JS/CSS/图片/字体/静态HTML）
静态资源内容变更频率极低，优先设置长时效强缓存，搭配ETag/Last-Modified协商缓存，同时通过文件哈希命名解决「缓存更新不及时」问题（核心方案）。
- 基础缓存配置（HTTP响应头）
Code block
| 1 | #推荐配置（生产环境）：强缓存1年+协商缓存+公共缓存+不可变 |
|---|---|
| 2 | Cache-Control: public, max-age=31536000, immutable |
| 3 | ETag: "xxx哈希值" |
| 4 | Last-Modified: [资源最后修改时间] |
- 实操（工程化）：
• Webpack/Vite打包时，对JS/CSS/图片自动生成contenthash： main.[contenthash].js
• CDN同步缓存哈希资源，最大化利用CDN节点缓存
• 入口 index.html：设置 Cache-Control: no-cache，强制协商缓存，保证每次请求都获
取最新的资源列表
- 细分资源缓存策略
• 图片/字体/视频： max-age=31536000 (1年) + immutable + ETag，永久强缓存，哈希
更新兜底。
- JS/CSS： max-age=31536000 + immutable + ETag，结合工程化哈希打包，极致缓存。
- 静态HTML（非入口）： max-age=86400 (1天) + ETag，短时效强缓存，兼顾更新。
✅ 二、入口文件（index.html，核心枢纽）
入口文件是所有静态资源的引用入口，禁止强缓存，必须设置协商缓存，否则静态资源哈希更新后，浏览器仍读取旧的index.html，导致加载旧资源。
推荐配置
Code block
| 1 | Cache-Control: no-cache, must-revalidate |
|---|---|
| 2 | ETag: "xxx哈希值" |
| 3 | Last-Modified: [更新时间] |
- 效果：每次请求都与服务器协商，保证获取最新的资源引用，同时复用缓存（304），无性能损
耗。
✅ 三、动态资源（如接口数据、动态接口、用户信息）
动态资源内容实时变更，禁止强缓存，按需设置协商缓存或完全禁用缓存，避免返回过期数据。
- 实时接口（如支付、用户信息、实时数据）：完全禁用缓存
Code block
1Cache-Control: no-store, no-cache
全站分卷索引 · 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属性；同时对敏感操作（如修改密
- • 用户退出登录时清理数据：用户点击退出登录后，前端需清除存储的令牌、权限信息等，同时调用
- • 敏感操作二次验证：对核心敏感操作（如修改密码、绑定手机号、大额转账），添加验证码、短信
- 四、常见问题与避坑要点
- • ❌ 仅依赖前端权限控制：后端必须对所有敏感接口进行权限验证，前端权限控制仅为用户体验优