CDN能加速静态资源加载，因其将文件缓存至离用户最近的边缘节点，请求时就近返回，大幅降低延迟；首次未命中则回源拉取并缓存，后续请求直接命中，关键在“近”和“已有”。
CDN 为什么能加速静态资源加载
因为浏览器请求 https://cdn.example.com/style.css 时，并不直接连源站，而是被 DNS 引导到离你最近的边缘节点——那个节点上大概率已缓存了这份文件，毫秒级返回，跳过了跨省甚至跨国的长链路。
关键不在“快”，而在“近”和“已有”。如果第一次访问该资源，边缘节点没缓存，它会自动向源服务器发起回源请求（Origin Pull），拿到后存一份再返回给用户；后续请求就全走本地缓存了。
- 静态资源（
.js、.css、.png）必须带版本号或哈希后缀（如app.a1b2c3.js），否则 CDN 可能因缓存策略复用旧内容 - HTML 文件一般不走 CDN 缓存（或设极短
max-age=0），否则用户看不到最新页面结构 - CDN 缓存是否生效，跟请求头中的
Cache-Control和ETag强相关，不是上传了就自动缓存
DNS 解析阶段到底发生了什么
你在地址栏输入域名，浏览器先查本地 DNS 缓存；没命中，就发请求给本地 DNS（比如你路由器设的 114.114.114.114）；这个 DNS 不直接返回 IP，而是看到 CNAME 记录（例如 static.yoursite.com → your-site.cdnprovider.net），于是转向 CDN 提供商的权威 DNS 查询。
这个权威 DNS 就是调度大脑：它根据请求来源的 IP 地理位置、运营商（电信/联通/移动）、当前各边缘节点负载，选出一个最优节点，返回其 IP 地址。
立即学习“前端免费学习笔记（深入）”；
- 如果你的本地 DNS 是公共 DNS（如
8.8.8.8），它可能把北京用户解析到广州节点——因为它的出口 IP 被识别为广东某 IDC，导致“就近”失效 - CNAME 必须配置正确：
static.yoursite.com的 DNS 记录类型必须是CNAME，不能是A记录，否则绕过 CDN 调度逻辑 - 修改 CNAME 后，TTL 过期前（常见 300–3600 秒）旧解析仍有效，无法立刻生效
缓存未命中（Miss）时的回源行为
边缘节点没缓存时，它会以自己的身份（不是用户 IP）向你配置的源站发起 HTTP 请求，这个过程叫“回源”。回源地址是你在 CDN 控制台填的 Origin Server，比如 https://origin.yoursite.com。
注意：回源请求的 Host 头默认是源站域名，不是用户访问的 CDN 域名；若源站做了 Host 校验或 HTTPS 证书绑定，需确认是否兼容。
- 回源协议建议用 HTTPS，避免中间链路被劫持或降级
- 回源超时时间建议设为 30s 左右；太短易失败，太长拖慢首字节时间（
TTFB） - 部分 CDN 支持“回源跟随 302”，即源站返回重定向时，边缘节点自动跟进跳转并缓存最终目标内容——但要确认是否开启，否则可能缓存 302 响应本身
怎么验证 CDN 是否真在工作
别只看网页加载变快了。打开 DevTools → Network 面板，点开任意一个静态资源，看响应头里的 X-Cache（或类似字段，如 X-Cache-Hit、X-CDN-Status）：
若值为 HIT，说明走了缓存；MISS 表示本次回源；EXPIRED 或 STALE 说明缓存过期但可能用了 stale-while-revalidate 策略。
- 同时检查
Age响应头：非零值（如Age: 1245）代表该响应已在 CDN 节点缓存了 1245 秒 - 对比请求的
Server头：如果是nginx或你源站的标识，说明没走 CDN；若是cloudflare、akamai、alidns等，则大概率已接入 - 用
curl -v https://cdn.yoursite.com/app.js 2>&1 | grep "X-Cache\|Age\|Server"快速命令行验证，避开浏览器缓存干扰
最常被忽略的一点：CDN 加速效果高度依赖资源本身的可缓存性。一个没设 Cache-Control: public, max-age=31536000 的 JS 文件，哪怕放在 CDN 上，每次都是 MISS。优化起点永远是响应头，不是换服务商。
