One post tagged with "网络"

跨域​

想象一下，你曾经或者正登录着银行网站（bank.com），同时在另一个标签页打开了一个恶意网站（evil.com）。

如果没有跨域限制，evil.com 里的 JS 脚本可以轻而易举地：

• 读取你银行网站的 Cookie。
• 冒充你向银行发送「转账」请求。
• 读取你的私人账单数据。

这就是著名的 CSRF^?（跨站请求伪造） 和 数据泄露 风险。为了防止这种「大乱斗」，浏览器强制执行了 同源策略^?（Same-Origin Policy）。

虽然跨域有限制，但现代互联网需要资源共享（比如你的博客引用自己的云音乐平台的歌曲，通过脚本读取音频渲染出跳动的音符）。于是有了 CORS^?（Cross-Origin Resource Sharing，跨源资源共享）。

它本质上是服务器与浏览器之间的一次对话：

1. 浏览器问： 「嘿，服务器，我这有个来自 abc.com 的网页，想拿你的 MP3，准吗？」
2. 服务器答（响应头）： 「准了！我带上 Access-Control-Allow-Origin: https://abc.com。」

如果你是一个善良的免费平台，你也可以用*表示所有人都可以访问：Access-Control-Allow-Origin: *

3. 浏览器看： 「嗯，名单上有它，放行！」

CORS 是白名单制度。服务器必须明确说出允许谁访问。

如果服务器没配 Header，或者缓存了没头的响应，浏览器会一直拒绝！

如果你的代码之前通过 audio 标签在浏览器里缓存了一个音频（不带 Access-Control-Allow-Origin），之后又改为用 fetch 获取这个资源，浏览器会从缓存里取出无 CORS 头的旧响应提供给 fetch，并在控制台提示该资源被拦截。

建议： 给 audio 标签加上 crossOrigin="anonymous"。这样 audio 和 fetch 都会要求服务器返回 CORS 头。

为了避免相同资源被频繁读取，不只是浏览器，整个网络都充满了各种各样的缓存。

缓存链路​

浏览器缓存​

缓存条目的 Response Headers 在开发者工具里不会展示 Access-Control-Allow-Origin，给排查带来一定困难。

chrome://net-export/ 是 Chrome 最强大的网络日志工具，可将所有网络行为（包括读取缓存的细节）记录到一个 JSON 文件中。

操作步骤：

• 在地址栏输入 chrome://net-export/。
• 点击 "Start Logging to Disk"，选择保存位置。
• 回到你的博客页面刷新，重现那个 from disk cache 的请求。
• 回到日志页面点击 "Stop Logging"。
• 使用 NetLog Viewer 打开该 JSON。
• 在日志中搜索 HTTP_CACHE_GET_HEADERS，即可看到缓存里所有原始的 Response Headers。

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2021 22:22:22 GMT

浏览器分析​

下面是一段 Chrome NetLog 的片段：

{"params":{"batch_id":0,"encryption_level":"ENCRYPTION_FORWARD_SECURE","packet_number":452,"sent_time_us":472946859030,"size":1250,"transmission_type":"NOT_RETRANSMISSION"},"phase":0,"source":{"id":19077,"start_time":"471676479","type":12},"time":"472946859","type":313},

{"phase":2,"source":{"id":27027,"start_time":"472946851","type":14},"time":"472946862","type":156},

{"params":{"cors_preflight_policy":"consider_preflight","is_revalidating":false,"request_headers":{"headers":["sec-ch-ua-platform: \"Windows\"","Accept-Encoding: identity;q=1, *;q=0","User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36","sec-ch-ua: \"Not:A-Brand\";v=\"99\", \"Google Chrome\";v=\"145\", \"Chromium\";v=\"145\"","Range: bytes=0-","sec-ch-ua-mobile: ?0","Accept: */*"],"line":"GET /static/summary/blog_2026_2_28_.mp3 HTTP/1.1\r\n"},"url":"https://chat.jiangyang.fun/static/summary/blog_2026_2_28_.mp3"},"phase":1,"source":{"id":27030,"start_time":"472946868","type":1},"time":"472946868","type":576},

[事件 27030] 媒体资源加载日志

• 目标： AI 总结音频（blog_2026_2_28_.mp3）
• 浏览器行为： 通过 HTTP/1.1 获取资源
• 安全决策： 启用 CORS 策略检查（consider_preflight）
• 请求头特征： 带有 Range: bytes=0-（请求媒体流）、Chrome 145 的 User-Agent
• 底层状态： 发送了编号为 452 的加密封包，大小 1.25KB，传输正常

另一条日志中的缓存 Key：

{"params":{"created":false,"key":"Range_1/0/_dk_https://jiangmiemie.com https://jiangmiemie.com https://chat.jiangyang.fun/static/summary/blog_2026_2_28_.mp3:2faabf977670a1:0"},"phase":1,"source":{"id":27032,"start_time":"472946870","type":14},"time":"472946870","type":156},

这个字符串是浏览器在磁盘上查找缓存的「身份证号」，由以下几部分组成：

• Range_1/0/： 分段缓存，表示该音频曾被分段请求并缓存。
• dk（Double Keying^?）： 双重键值。现代浏览器不再只按 URL 缓存，而是按「顶层站点 + 请求来源 + 资源 URL」组合缓存。
• https://jiangmiemie.com： Top-level Site（顶层站点）。
• https://jiangmiemie.com： Frame Origin（请求来源）。
• https://chat.jiangyang.fun/static/...mp3： 资源真实 URL。

结论 A：缓存已经彻底「分区」了

由于 Key 里包含了 https://jiangmiemie.com，这个缓存条目是专门为你的博客页面生成的。即使你直接在地址栏访问该 MP3，浏览器会使用另一套 Key（不含来源域名）。跨域访问与直接访问对应两套独立的缓存条目；当前命中的是带 CORS 头的健康版本。

结论 B：created: false 意味着命中

"created": false 表示没有新建缓存条目，而是命中了已有条目，请求确实来自 disk cache。命中带 jiangmiemie.com 的 Key，说明该缓存项在写入时已通过跨域校验并记录了来源信息。

结论 C：双重验证通过

日志中的 2faabf977670a1 是该缓存条目的哈希指纹。只要该 ID 对应的资源能正常加载，说明其内部存储的 Access-Control-Allow-Origin 头是完整的。

未雨绸缪​

若在商业项目中遇到类似问题：某资源未配置跨域，用户端首页大图裂开，CDN 已分发、用户浏览器也已缓存错误响应。如何紧急处理、避免 T0 事故？

思路：把「图片名称」和「真实地址」分离，例如配置里只存 "home_banner_url": "v1.png"，真实 URL 由配置中心下发。

前端初始化时接入配置中心 SDK（例如 Nacos^?），通过 WebSocket 或长轮询维持连接：

// configClient.js（伪代码）
import { ConfigClient } from 'nacos-sdk';

export const config = {
  home_banner_url: "https://cdn.com/image.png"
};

client.subscribe({ dataId: 'app_config' }, (content) => {
  const newConfig = JSON.parse(content);
  config.home_banner_url = newConfig.home_banner_url;
  store.dispatch({ type: 'UPDATE_CONFIG', payload: config });
});

组件不写死 src，而是从全局状态读取当前 URL：

// BannerComponent.jsx
import { useSelector } from 'react-redux';

const Banner = () => {
  const bannerUrl = useSelector(state => state.config.home_banner_url);
  return (
    <div className="banner">
      <img src={bannerUrl} alt="首页大图" />
    </div>
  );
};

场景： 早上 10:00，发现 image.png 因 CORS 缓存污染在全球范围裂开。

紧急修复（无需发版）：

1. 打开 Nacos 管理后台，将 home_banner_url 从 .../image.png 改为 .../image.png?v=0304_fix，点击发布。
2. 正在运行的前端通过 WebSocket 收到新配置，React 状态更新，img 的 src 变为新 URL。
3. 浏览器将新 URL 视为新资源，绕过旧缓存，向 CDN 请求最新图片。
4. 用户无感刷新，裂图恢复。

参考链接​

• MDN - CORS
• Cloudflare - CORS 与缓存