全面解析HTTP缓存机制：从浏览器缓存到代理缓存

1. 缓存体系概述

HTTP缓存体系主要分为三类：

• 浏览器缓存（私有缓存）：存储在用户浏览器中，仅对单个用户有效
• 代理缓存（共享缓存）：位于客户端和服务器之间的缓存（如CDN、反向代理、网关等），可为多个用户提供服务
• 混合缓存：Service Worker等现代混合缓存机制

2. 强缓存（本地+代理）

强缓存阶段不发送请求到源服务器，直接使用缓存副本。

控制字段

Cache-Control (HTTP/1.1)

• public：响应可被任何缓存（包括浏览器和代理）存储
• private：响应只能被浏览器缓存（不允许代理缓存）
• max-age=<seconds>：缓存有效期（相对时间）
• s-maxage=<seconds>：专门设置代理缓存的有效期（优先级高于max-age）
• no-store：禁止任何缓存
• no-cache：不使用强缓存，立即进入协商缓存
• immutable：资源永不变（仅限浏览器缓存）

Expires (HTTP/1.0)

• 绝对过期时间（如Expires: Thu, 31 Dec 2037 23:55:55 GMT）
• 缺点：依赖客户端时间同步

代理缓存特殊处理

1

Cache-Control: public, max-age=3600, s-maxage=7200

表示：

• 浏览器缓存1小时（3600秒）
• 代理缓存2小时（7200秒）

强缓存生效流程

1
2
3
4

graph TD
    A[请求资源] --> B{缓存是否存在且有效}
    B -->|是| C[直接使用缓存]
    B -->|否| D[向服务器发起请求]

3. 协商缓存

当强缓存失效时，客户端携带验证信息向服务器确认资源有效性。

验证机制

1. Last-Modified / If-Modified-Since

• 服务器响应头：Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
  • 生成方式：文件系统中资源的最后修改时间
• 客户端请求头：If-Modified-Since: <Last-Modified-value>
  • 流程：如果服务器资源修改时间 > 客户端提供的值，则返回新资源(200)；否则返回304

2. ETag / If-None-Match

• 服务器响应头：ETag: <etag_value>
  • 生成方式：
    • 强ETag：字节级匹配（如"5d83c2-55e-7f7163f3b5d00"）
    • 弱ETag：语义匹配（如W/"5d83c2-55e-7f7163f3b5d00"）
  • 常见生成算法：

    1 2	# Nginx配置示例（默认使用弱校验） etag on; # 默认基于最后修改时间+内容长度计算

    1	# Apache默认使用inode+修改时间+大小

• 客户端请求头：If-None-Match: <etag_value>
  • 流程：服务器计算当前ETag与客户端值匹配则返回304，否则返回200

对比分析

协商缓存流程

1
2
3
4
5
6
7
8
9

sequenceDiagram
    participant Client
    participant Server
    Client->>Server: GET /resource <br> If-None-Match: "abc123" <br> If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT
    alt 资源未修改
        Server-->>Client: 304 Not Modified <br> (空Body)
    else 资源已修改
        Server-->>Client: 200 OK <br> Last-Modified: ... <br> ETag: "def456" <br> [Resource Data]
    end

304状态码详解

• 语义：Not Modified（资源未修改）
• 特点：
  • 无响应体（节省带宽）
  • 必须包含更新的缓存头（如Date等）
• 效果：指示客户端重用现有缓存

4. 缓存策略实践场景

不同资源类型的缓存配置

5. 预加载技术

<link rel="preload">

目的：声明当前页面关键资源，提前加载

1
2

<!-- 预加载关键字体 -->
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

特点：

• 资源优先级提升为High
• 必须指定as属性（font/image/script/style等）
• 浏览器立即发起请求

<link rel="prefetch">

目的：预测用户下一步操作，提前缓存资源

1
2

<!-- 预取下一页资源 -->
<link rel="prefetch" href="next-page.html" as="document">

特点：

• 优先级为Lowest
• 浏览器空闲时加载
• 缓存时间短（Chrome默认5分钟）

使用场景对比

6. Service Worker缓存

核心能力

• 完全控制网络请求（拦截/修改/缓存）
• 离线运行能力
• 后台同步

缓存策略实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 示例：Stale-While-Revalidate策略
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open('runtime-cache').then(cache => {
      return cache.match(event.request).then(cachedResponse => {
        const fetchPromise = fetch(event.request).then(networkResponse => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return cachedResponse || fetchPromise;
      });
    })
  );
});

典型应用场景

1. 离线应用：缓存核心资源实现离线访问
2. 性能优化：缓存API响应提升二次访问速度
3. 降级方案：网络不可用时提供基础功能
4. 资源更新：后台静默更新缓存资源

7. 代理缓存详解

工作特性

• 位置：客户端与源服务器之间
• 优势：
  • 减少源服务器负载
  • 降低网络延迟（就近访问）
  • 抵御流量高峰
• 缓存控制：
  • 遵循Cache-Control的public/s-maxage指令
  • 可忽略Vary头（某些代理）

代理缓存失效

1. 传统方式：等待缓存过期
2. 主动清除：
   • CDN管理界面清除缓存
   • 通过API触发刷新（如POST /purge）
3. 内容变更：
   • 修改URL（推荐）
   • 使用缓存破坏参数（需配置代理支持）

8. 高级缓存问题

缓存中毒（Cache Poisoning）

• 成因：代理缓存存储了包含用户特定信息的响应
• 防御：
  • 正确设置Vary头（如Vary: Cookie, User-Agent）
  • 敏感内容使用private

多版本资源处理

1

Vary: Accept-Encoding, User-Agent

指示代理根据Accept-Encoding和User-Agent字段缓存不同版本资源

总结：缓存优先级与决策树

优先级总则

1. Cache-Control > Expires
2. ETag > Last-Modified
3. s-maxage > max-age（对代理缓存）

缓存决策流程

1
2
3
4
5
6
7
8
9

graph TD
    A[请求资源] --> B{是否存在有效强缓存}
    B -->|是| C[返回200 from cache]
    B -->|否| D{是否配置协商缓存}
    D -->|否| E[从服务器获取]
    D -->|是| F[发送验证请求]
    F --> G{服务器验证}
    G -->|未修改| H[返回304使用缓存]
    G -->|已修改| I[返回200新资源]

掌握HTTP缓存机制是Web性能优化的核心技能。合理配置浏览器缓存、代理缓存和Service Worker缓存，配合预加载技术，可显著提升用户体验并降低服务器成本。

跨域：原理、机制与解决方案

一、什么是跨域？

跨域（Cross-Origin） 是指浏览器出于安全考虑，限制网页脚本向不同源（协议+域名+端口） 的服务发起请求的行为。这是浏览器实现的同源策略（Same-Origin Policy） 所导致的安全限制。

同源策略三要素

1. 协议相同（HTTP/HTTPS）
2. 域名相同（www.example.com）
3. 端口相同（80/443）

示例：

二、跨域场景分析

1. 常见跨域场景

• 前端与API分离：https://web.com 请求 https://api.com
• 微服务架构：https://service1.com 请求 https://service2.com
• CDN资源：https://main.com 加载 https://cdn.com/resource.js
• 第三方服务：https://myapp.com 接入 https://maps.google.com

2. 跨域限制范围

三、浏览器跨域判断机制

1. CORS（跨域资源共享）流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

sequenceDiagram
    participant Browser
    participant Server
    
    Browser->>Server: 发送跨域请求（带Origin头）
    alt 简单请求
        Server-->>Browser: 响应包含Access-Control-Allow-Origin
        Browser->>Browser: 检查响应头是否匹配Origin
    else 复杂请求
        Browser->>Server: 先发送OPTIONS预检请求
        Server-->>Browser: 返回CORS策略头
        Browser->>Browser: 验证策略是否允许
        Browser->>Server: 发送实际请求
        Server-->>Browser: 返回实际响应
    end

2. 核心响应头字段

四、跨域解决方案详解

1. CORS（跨域资源共享）

服务端配置示例（Node.js）：

1
2
3
4
5
6
7
8
9
10
11
12
13

app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', 'https://web.com');
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  res.setHeader('Access-Control-Max-Age', '86400');
  
  if (req.method === 'OPTIONS') {
    return res.sendStatus(200);
  }
  
  next();
});

2. JSONP（JSON with Padding）

原理：利用<script>标签不受同源策略限制的特性

1
2
3
4
5
6
7
8
9
10
11

// 客户端
function handleResponse(data) {
  console.log('Received:', data);
}

const script = document.createElement('script');
script.src = 'https://api.com/data?callback=handleResponse';
document.body.appendChild(script);

// 服务端响应
handleResponse({"name": "John", "age": 30});

局限性：

• 仅支持GET请求
• 缺乏错误处理机制
• 存在XSS风险

3. 反向代理

原理：同源请求代理服务器 → 代理转发到目标服务器

Nginx配置示例：

1
2
3
4
5
6
7
8
9
10

server {
    listen 80;
    server_name web.com;
    
    location /api/ {
        proxy_pass https://api.com/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

4. WebSocket

1
2
3
4
5
6
7
8
9
10

// 客户端
const socket = new WebSocket('wss://api.com/ws');

socket.onopen = () => {
  socket.send(JSON.stringify({action: 'subscribe'}));
};

socket.onmessage = (event) => {
  console.log('Data:', JSON.parse(event.data));
};

5. postMessage

跨窗口通信：

1
2
3
4
5
6
7
8
9

// 发送方（https://web.com）
const iframe = document.getElementById('other-site');
iframe.contentWindow.postMessage('Hello!', 'https://other.com');

// 接收方（https://other.com）
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://web.com') return;
  console.log('Received:', event.data);
});

6. 现代浏览器API

跨域资源共享代理：

1
2
3

// 使用CORS代理服务
fetch('https://cors-proxy.com/https://api.com/data')
  .then(response => response.json())

浏览器支持：

1
2
3
4
5
6

pie
    title 跨域方案浏览器支持率
    "CORS" : 98
    "postMessage" : 97
    "WebSocket" : 95
    "JSONP" : 99

五、OPTIONS预检请求详解

1. 什么情况下触发OPTIONS请求？

• 使用非简单请求方法（PUT/DELETE等）
• 包含非标准请求头（自定义头）
• Content-Type为application/json
• 请求中带身份凭证（credentials）

2. OPTIONS请求示例

1
2
3
4
5

OPTIONS /api/user HTTP/1.1
Host: api.com
Origin: https://web.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: X-Custom-Header

3. 服务端响应示例

1
2
3
4
5
6

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://web.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 86400
Access-Control-Allow-Credentials: true

4. 优化建议

• 使用Access-Control-Max-Age减少预检请求
• 合并多个自定义头减少预检次数
• 尽可能使用简单请求

六、简单请求 vs 复杂请求

1. 简单请求条件

1. 方法限制：
   • GET
   • HEAD
   • POST
2. 头限制：
   • Accept
   • Accept-Language
   • Content-Language
   • Content-Type（仅限于以下值）：
     • text/plain
     • multipart/form-data
     • application/x-www-form-urlencoded

简单请求流程：

1. 浏览器直接发送跨域请求（带Origin头）
2. 服务器响应包含CORS头
3. 浏览器验证响应头

2. 复杂请求条件

任何不符合简单请求条件的请求，包括：

• PUT、DELETE、PATCH等方法
• Content-Type为application/json
• 包含自定义头（如Authorization）

复杂请求流程：

1. 浏览器发送OPTIONS预检请求
2. 服务器响应预检请求
3. 浏览器验证通过后发送实际请求
4. 服务器响应实际请求

3. 对比总结

七、表单提交与跨域

1. 表单提交的特性

1
2
3
4

<form action="https://other.com/api" method="POST">
  <input type="text" name="username">
  <button type="submit">提交</button>
</form>

关键特性：

• ✅ 允许跨域提交：浏览器不会阻止表单的跨域提交
• 🔄 页面跳转：表单提交后浏览器会导航到目标URL
• ❌ 响应受限：提交后浏览器会离开当前页面，无法直接处理跨域响应

2. AJAX表单提交的跨域问题

1
2
3
4
5
6
7
8
9
10

// 使用AJAX提交表单
const formData = new FormData(document.getElementById('myForm'));

fetch('https://other.com/api', {
  method: 'POST',
  body: formData
}).then(response => {
  // 这里会触发跨域检查
  console.log(response);
});

结果：

• 需要服务端配置CORS响应头
• 否则浏览器会阻止JavaScript读取响应

3. 解决方案

1. 传统表单：接受页面跳转
2. AJAX提交：
   • 服务端配置CORS
   • 使用代理服务器中转
3. 隐藏iframe技巧：

   1 2 3 4

   <form target="hiddenFrame" action="https://other.com/api" method="POST"> <!-- 表单内容 --> </form> <iframe name="hiddenFrame" style="display:none"></iframe>

八、安全最佳实践

1. 精确配置CORS：

   1 2	// 避免使用通配符* res.setHeader('Access-Control-Allow-Origin', 'https://trusted-domain.com');

2. 凭证控制：

   1 2 3 4 5

   // 前端 fetch(url, { credentials: 'include' }); // 后端 res.setHeader('Access-Control-Allow-Credentials', 'true');

3. CSRF防护：

   • 使用SameSite Cookie属性
   • 实现CSRF令牌机制
   • 验证Origin/Referer头

4. 避免JSONP安全风险：

   • 严格验证回调函数名
   • 实施内容安全策略（CSP）
   • 优先使用CORS替代JSONP

九、现代跨域技术趋势

1. 跨域隔离（Cross-Origin Isolation）：

   • 使用COOP（Cross-Origin Opener Policy）
   • 使用COEP（Cross-Origin Embedder Policy）

     1 2	Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp

2. SharedArrayBuffer：

   • 需要跨域隔离环境
   • 启用高性能并行计算

3. 联邦学习（Federated Learning）：

   • 跨域数据协作新范式
   • 隐私保护下的模型训练

4. Web容器技术：

   • 微前端架构
   • 模块联邦（Module Federation）

总结

跨域是现代Web开发中的核心问题，理解其原理和解决方案至关重要：

1. 同源策略是浏览器安全基石，限制跨域脚本交互
2. CORS是主流解决方案，需前后端协作实现
3. 简单请求直接发送，复杂请求需要预检
4. 表单提交允许跨域但导致页面跳转
5. OPTIONS预检是复杂请求的必要步骤
6. 多种替代方案适用于不同场景（JSONP/代理/WebSocket等）

随着Web生态发展，跨域技术也在不断演进。开发人员应掌握核心原理，根据实际需求选择适当方案，同时关注新兴的跨域安全模型和技术趋势。