CDN：内容分发网络与静态资源加速
CDN 是什么
CDN，全称是 Content Delivery Network，中文通常叫内容分发网络。
它不是某一台服务器，而是一套分布在不同地域、不同运营商网络中的边缘节点集群。它的核心目标是：把用户要访问的资源提前缓存或分发到离用户更近、网络质量更好的节点上，让用户不必每次都跨地域、跨运营商访问源站。
可以把 CDN 理解成“离用户更近的资源中转站”：
在前端项目中，CDN 最常用于加速静态资源，例如 JavaScript、CSS、图片、字体、音视频、下载文件等。对于动态接口，CDN 也可以做边缘缓存、接口加速、安全防护和请求转发，但是否适合缓存，需要看业务数据是否允许被多个用户共享。
CDN 解决了什么问题
降低访问延迟
如果一个中国用户访问部署在美国的源站，网络请求可能要经过较长的国际链路。使用 CDN 后，用户可能访问的是本地或邻近城市的边缘节点，TCP/TLS 建连时间和数据传输时间都会明显下降。
减轻源站压力
大量静态资源请求会被 CDN 节点直接响应，源站只需要处理缓存未命中、资源过期校验、动态请求或管理类请求。对于大促、活动页、图片站、下载站等场景，这一点非常关键。
提高可用性
CDN 厂商通常拥有多节点、多线路、多运营商调度能力。某个节点异常时，可以把流量调度到其他节点；对于已经缓存在边缘节点上的资源，请求会直接由 CDN 返回，减少对源站可用性和瞬时负载的依赖。
改善跨运营商访问
不同运营商之间的互联质量可能不稳定。所谓跨运营商访问，指的是用户所在网络和资源所在服务器不在同一个运营商网络里。例如用户使用中国移动宽带，但源站部署在中国电信机房，请求就可能经过移动网络、电信网络以及两者之间的互联出口：
跨运营商链路在高峰期可能出现延迟升高、丢包、拥塞和下载速度不稳定。CDN 的做法是在多个运营商网络中部署边缘节点，并通过调度系统尽量让用户访问同运营商或链路质量更好的节点：
如果 CDN 节点缓存命中，请求会直接在边缘节点返回，不需要跨运营商访问源站。即使缓存未命中，需要由 CDN 节点回源，跨运营商或跨地域链路也主要发生在 CDN 到源站之间，而不是每个用户都直接承受这条链路。
提供安全与流量治理能力
实际 CDN 服务通常还会集成 HTTPS 证书托管、访问控制、防盗链、限速、WAF、DDoS 防护、日志分析、边缘规则、图片处理等能力。严格来说，这些不是 CDN 的最基础定义，但在真实项目里经常与 CDN 一起使用。
CDN 的核心组成
源站
源站是资源的原始服务器，可以是业务服务器、对象存储、静态资源服务器或负载均衡入口。CDN 节点没有资源或缓存过期时，会向源站请求资源，这个过程叫回源。
例如：
用户访问 static.example.com/assets/app.8f3a1c.js，CDN 节点如果没有缓存，就会去源站请求 /assets/app.8f3a1c.js。
边缘节点
边缘节点是离用户更近的 CDN 缓存服务器。它负责接收用户请求，判断本地是否有可用缓存：
- 命中缓存：直接返回资源。
- 未命中缓存：向上层 CDN 节点或源站请求资源，拿到响应后按策略缓存，再返回给用户。
- 缓存过期：根据缓存策略重新验证或重新拉取资源。
用户请求 CDN 资源时，DNS 最终返回的通常不是源站 IP，而是某个 CDN 边缘节点、节点集群或负载均衡入口的 IP：
这里的 203.0.113.10 就可以理解成 CDN 边缘节点 IP。浏览器拿到这个 IP 后，会和这个 CDN 节点建立 TCP/TLS 连接，再发送 HTTP 请求。
但“CDN 节点”通常不是单台服务器，而是某个区域或运营商网络中的边缘服务集群。DNS 返回的节点 IP 可能是某台缓存服务器的 IP，也可能是负载均衡入口、VIP、Anycast IP，或多台缓存服务器共同对外服务的一组 IP。请求进入节点后，节点内部还可能继续做负载均衡，把请求分配给具体缓存服务器处理。
一般业务公司不需要自己购买这些节点。公司购买的是 CDN 服务，边缘节点、机房、带宽、IP、缓存集群和调度系统由 CDN 厂商建设和维护。业务方需要配置加速域名、源站、缓存规则、证书和安全策略。
调度系统
调度系统决定用户应该访问哪个 CDN 节点。常见调度方式包括 DNS 调度、HTTPDNS、Anycast IP、302 调度等。前端面试中最常见的是 DNS 调度。
DNS 调度中有一个重要概念：调度域名。它通常是 CDN 厂商给业务方的 CNAME 目标，用来把某个业务加速域名的后续 DNS 解析引到 CDN 厂商。
static.example.com 是用户访问的业务加速域名，static.example.com.cdnvendor.net 是 CDN 厂商提供的调度域名。调度域名本身不存放资源，它的作用是把 DNS 查询引到 CDN 厂商控制的解析体系。
当递归 DNS 继续查询 static.example.com.cdnvendor.net 时，请求会到达 CDN 厂商的权威 DNS。这个权威 DNS 负责对 CDN 厂商自己的域名区域给出最终解析结果；它通常会结合背后的调度系统，根据用户大致位置、运营商、节点健康、节点负载和线路质量等因素，返回一个或多个合适的边缘节点 IP。
所以，CDN 厂商的权威 DNS 是 DNS 查询入口和响应出口，调度系统是背后的节点选择逻辑。二者配合完成 DNS 调度，但不能简单理解成同一个东西。
业务方通常不会直接把加速域名配置成 CDN 节点 IP 的 A 记录。因为 CDN 节点数量很多，而且会随地域、运营商、节点健康、节点负载、容量调整和故障切换动态变化。如果业务方直接维护这些 IP，不仅维护成本高，也会失去 CDN 厂商按实时网络质量做调度的能力。使用 CNAME 指向 CDN 调度域名，本质上是把“具体返回哪个边缘节点 IP”这件事交给 CDN 厂商处理。
缓存系统
缓存系统负责保存资源副本，并根据 HTTP 缓存头、CDN 控制台规则、缓存键、刷新预热策略决定资源是否可缓存、缓存多久、什么时候回源。
它不是简单地“按 URL 存文件”。真实 CDN 会先判断响应是否允许被共享缓存，例如是否有 Cache-Control: public，是否包含 private、no-store、Set-Cookie、Authorization 等敏感信号；然后根据协议、域名、路径、查询参数，以及部分请求头或 Cookie 生成缓存键。
当请求到达边缘节点时，缓存系统会判断资源是命中、未命中还是已过期：命中时直接返回；未命中时回源拉取；过期时可能重新回源拉取，也可能通过 ETag、Last-Modified 与源站做协商校验。缓存系统设计不好，可能导致命中率低、回源压力大、旧资源迟迟不更新，甚至把用户私有数据错误缓存给其他用户。
回源链路
回源链路是 CDN 节点到源站之间的请求路径。为了减少源站压力，CDN 可能存在多级缓存：
多级缓存可以避免大量边缘节点同时打到源站。
一次 CDN 请求的完整链路
以页面引用一个静态脚本为例：
用户第一次请求该资源时，链路通常如下：
可以画成更直观的形式：
第二个用户或同一用户再次请求时，如果命中 CDN 缓存，链路会短很多：
用户访问的是 CDN 节点，但 URL 中的域名仍然是业务域名 static.example.com。HTTPS 证书也需要覆盖这个域名，TLS 握手通常发生在浏览器和 CDN 节点之间。CDN 再回源时，可以使用 HTTP 或 HTTPS，真实项目中更推荐 HTTPS 回源。
DNS 调度与 CNAME
假设业务配置如下：
这里的 static.example.com.cdnvendor.net 不是资源服务器地址，不表示这个域名背后有一台机器专门存放 app.js、logo.png。它更像一个 DNS 调度入口：递归 DNS 查询到这个域名时，会进入 CDN 厂商控制的权威 DNS。
static.example.com 属于业务域名 example.com，它的 CNAME 记录由 example.com 的权威 DNS 返回；static.example.com.cdnvendor.net 属于 CDN 厂商的域名 cdnvendor.net，所以最终解析它的是 CDN 厂商管理的权威 DNS。普通权威 DNS 往往返回预先配置好的记录，而 CDN 厂商的权威 DNS 背后接了调度系统，可以根据用户位置、运营商、节点健康、节点负载和线路质量，动态返回更合适的边缘节点 IP。
用户解析 static.example.com 时，大致过程是：
- 浏览器、操作系统、路由器或本地 DNS 先查缓存。
- 没有缓存时，递归 DNS 按 DNS 层级查询。
example.com的权威 DNS 返回static.example.com的 CNAME。- 递归 DNS 继续解析 CDN 厂商的调度域名。
- CDN 厂商的权威 DNS 根据递归 DNS 出口、EDNS Client Subnet、节点状态、负载和网络质量等信息返回 CDN 节点 IP。
- 浏览器拿到 IP 后，与该节点建连并发送请求。
完整过程可以这样理解：
这条链路遵循的是标准 DNS 协议：域名分层、递归查询、迭代查询、CNAME 继续解析、A / AAAA 返回地址、TTL 缓存等规则都是统一的。否则不同 DNS 服务商和客户端之间就无法互通。
不完全统一的是权威 DNS 收到查询后的返回策略。普通 DNS 服务可能只是返回预先配置好的固定记录，例如 www.example.com A 1.2.3.4；而 CDN 厂商的权威 DNS 背后通常接了调度系统，可以根据递归 DNS 来源 IP、EDNS Client Subnet、用户大致地域、运营商、节点健康、节点负载、网络质量、业务配置和成本等因素，动态返回不同边缘节点 IP。
所以，DNS 的协议规则是统一的；CDN 厂商的智能解析和调度策略可以不同。
这里要注意：CNAME 通常配置在 example.com 这个 DNS 区域的权威 DNS 中，而不是配置在一个单独的“static.example.com 的权威 DNS”中。因为 static.example.com 多数情况下只是 example.com 区域下的一条记录。
例如你购买并托管了 example.com，DNS 服务商负责 example.com 区域，那么可以在这个区域里配置：
也可以写成区域内的相对形式：
只有当你把 static.example.com 单独委派成一个子区域时，才会有所谓“static.example.com 的权威 DNS”。例如在 example.com 区域里配置：
这时 static.example.com 才成为独立 zone，后续 a.static.example.com、cdn.static.example.com 之类记录才由它自己的权威 DNS 管。实际 CDN 接入里通常只是给一个加速域名加一条 CNAME，不需要把它单独委派出去。
CNAME 本身不负责“选择节点”，它只负责把解析流程引到 CDN：
CDN 权威 DNS 不会固定返回同一个 IP，而是根据调度规则选择当前更适合这个用户访问的节点。
一个简化的调度流程可以这样理解：
传统 DNS 调度有一个限制：权威 DNS 通常看到的是递归 DNS 的地址，不一定能准确看到终端用户的真实地址。因此，如果用户使用了跨地区的公共 DNS，调度结果可能不够精准。EDNS Client Subnet 可以在一定程度上改善这个问题，但也会带来隐私和兼容性权衡。
这一步的目标不是“绝对最近”，而是“综合网络质量最合适”。物理距离近不一定代表访问质量最好。例如北京用户不一定永远拿到北京节点。如果北京节点故障、负载很高，或者北京节点与该用户运营商之间的链路质量不好，CDN 可能返回天津、河北、山东甚至其他区域的节点。
DNS 响应也可能返回多个边缘节点 IP：
多个 IP 通常用于负载均衡和容灾。递归 DNS 会把这些 IP 返回给客户端，之后由浏览器、操作系统或网络协议栈选择其中一个建立连接。客户端可能选择第一个 IP，也可能根据本地策略调整顺序；如果同时存在 IPv4 和 IPv6，还可能通过 Happy Eyeballs 机制并行或错峰尝试。
如果某个 IP 连接失败或超时，客户端可能继续尝试下一个 IP。建连成功后，浏览器通常会在连接可复用期间继续使用这个连接。也就是说，DNS 调度负责返回一组相对合适的候选地址，真正连接哪个 IP，是客户端在发起连接时完成的最后一步选择。
CDN 缓存策略
CDN 缓存和浏览器缓存都能减少重复请求，但它们位于不同位置，解决的问题也不同。
一次请求可能同时经过两层缓存：
浏览器本地缓存命中时，请求甚至不会发到 CDN；浏览器缓存过期但 CDN 缓存命中时，请求会到 CDN，但不会到源站；两者都未命中时，才会回源。
用户请求到达 CDN 节点后，节点会根据请求 URL、请求头和缓存配置生成缓存键，然后判断是否存在可用缓存。
缓存是否生效，通常由源站响应头和 CDN 配置共同决定。
静态构建资源
对于带内容哈希的 JS、CSS、图片等构建资源，常见策略是长期缓存：
原因是文件内容变化后文件名会变化，旧文件可以长期缓存，新页面会引用新文件。
HTML 入口文件
HTML 可以经过 CDN，但通常不适合长期强缓存。原因是 HTML 是资源入口，它决定当前页面引用哪些 JS、CSS 和图片。发布新版本时，HTML 里的资源引用会变化：
如果 HTML 被长期强缓存，用户可能一直拿到旧 HTML，从而继续加载旧 JS。因此，SPA 的 index.html 最常见策略是：
no-cache 不是完全不缓存，而是表示可以缓存，但使用缓存前必须向服务器或 CDN 验证是否仍然最新。如果内容没有变化，服务端可以返回 304 Not Modified，浏览器继续使用本地缓存；如果内容变化，则返回新的 HTML。
常见 HTML 缓存策略如下：
其中 s-maxage 主要给 CDN 这类共享缓存使用，优先级通常高于 max-age；private 表示响应只应被浏览器这类私有缓存保存，不应被 CDN 共享缓存保存。
动态接口：公共接口可以缓存
CDN 不只会缓存 JS、CSS、图片这类静态文件，也可以缓存动态接口的响应。关键不在于“接口是不是动态生成的”，而在于这个响应是否适合被多个用户共享，以及是否允许一定的数据延迟。
公开且允许短暂延迟的接口可以设置较短缓存：
适合缓存的接口通常具有这些特点：
- 响应对多个用户相同。
- 数据允许短时间延迟。
- 可通过 URL、请求头或查询参数明确区分版本和维度。
- 不包含用户隐私、权限、登录态数据。
例如文章详情、商品基础信息、公开配置、城市列表、公开排行榜等，虽然响应可能是后端动态生成的 JSON，但如果结果对多个用户相同，就可以设置短 TTL 或使用边缘缓存。
动态接口：私有接口不能公共缓存
登录态接口、订单信息、用户资料、购物车、账户余额等私有数据一般不应被公共 CDN 缓存。因为这些响应和用户身份相关，如果被 CDN 当成公共缓存，可能出现严重的缓存串数据问题：A 用户的订单被缓存后，B 用户请求同一 URL 时拿到了 A 的订单。
涉及用户隐私、账户、订单、权限的数据，应避免被共享缓存：
或者至少使用：
不要让带 Set-Cookie、Authorization 或用户身份信息的响应被公共 CDN 错误缓存。
如果身份相关接口确实要经过 CDN，通常也是为了链路加速、TLS 终止、WAF、DDoS 防护、访问控制、边缘鉴权或请求转发，而不是让它进入公共缓存。除非使用了严格的缓存键、私有缓存、鉴权和隔离策略，否则不要缓存这类响应。
缓存键
CDN 判断“两个请求是不是同一个缓存资源”，靠的是缓存键。默认情况下，缓存键通常包括协议、域名、路径和查询参数，也可能包括部分请求头。
例如：
如果 CDN 把完整查询参数纳入缓存键，这三个请求会被视为不同资源。真实项目里要特别关注：
- 是否忽略某些无意义参数，例如埋点参数
utm_source。 - 是否保留影响内容的参数，例如
width=400、format=webp。 - 是否按请求头区分缓存，例如
Accept-Encoding、Accept-Language。 - 是否按 Cookie 或 Authorization 区分缓存。
缓存键设计错误会导致两类问题：命中率低，或者更严重的缓存串数据。
发布与缓存更新
CDN 缓存更新主要有四种方式：自然过期、主动刷新、预热和版本化发布。实际项目里通常组合使用。
自然过期
自然过期是最基础的更新方式。CDN 会根据源站响应头或 CDN 控制台规则决定资源缓存多久。
表示资源可以缓存 86400 秒。缓存有效期内，CDN 命中后会直接返回资源；缓存过期后，CDN 会重新回源校验或拉取新资源。
自然过期的优点是简单，缺点是缓存没过期前用户可能一直拿到旧资源。因此，URL 不变但内容会更新的资源，不应只依赖很长的 TTL。
刷新
刷新是告诉 CDN 删除或标记某些缓存失效。用户下一次访问时，CDN 会重新回源拉取。
常见刷新方式：
- 按 URL 刷新：精确刷新某个文件。
- 按目录刷新：刷新某个路径下的资源。
- 按正则或规则刷新：部分 CDN 支持。
- 全站刷新：清空整个加速域名下的缓存，通常不建议频繁使用。
刷新适合修复错误资源、撤回内容、更新非哈希文件。但刷新不是越多越好，大量刷新会造成回源峰值。刷新通常也不是全网瞬间完成的，可能需要几十秒到几分钟传播，具体取决于 CDN 厂商、节点数量和刷新规模。
预热
预热是提前让 CDN 节点去源站拉取资源。这样用户第一次访问时也能尽量命中 CDN 缓存。
预热适合：
- 大促活动页资源。
- 大文件下载。
- 新版本发布后的核心静态资源。
- 热门图片、视频封面等高频资源。
刷新是“让旧缓存失效”，预热是“提前准备新缓存”。两者经常配合使用：先刷新错误或旧资源，再预热新资源，避免用户首次访问时集中回源。
版本化发布
前端 JS、CSS 和构建产物最推荐使用版本化发布，也就是文件名携带内容哈希，而不是覆盖旧文件。
旧版本：
新版本：
HTML 更新为引用新文件：
这样旧文件即使仍然缓存在 CDN 中也没关系，因为新页面请求的是新 URL。CDN 会把不同 URL 视为不同缓存对象：
推荐策略是：
这样做可以同时保证发布及时性和静态资源缓存收益：HTML 用短缓存或协商缓存，确保用户能拿到最新资源引用；带哈希的 JS、CSS、图片使用长缓存，减少重复下载。
旧 hash 资源如何删除
文件 hash 变化后，CDN 通常不会在新版本发布时立刻删除旧资源。因为旧资源和新资源是两个不同 URL，CDN 会把它们当成两个不同的缓存对象。新 HTML 引用新文件后，新用户会请求 /assets/app.d4e5f6.js；但仍然可能有用户拿着旧 HTML，继续请求 /assets/app.a1b2c3.js。
旧 hash 资源通常通过以下方式逐渐消失：
前端 hash 静态资源一般不需要发布后立刻主动刷新旧 URL。更推荐让旧资源保留一段时间，原因是：用户可能仍然持有旧 HTML，如果源站太早删除旧 JS，而某个 CDN 节点又没有缓存这个旧 JS，CDN 回源会得到 404，页面可能加载失败甚至白屏。
更稳妥的发布策略是：
因此，hash 文件名的价值不只是“方便强缓存”，还在于允许新旧资源并存，避免发布瞬间强制清理缓存带来的不可用风险。
CDN 与 HTTPS 和安全
使用 HTTPS 的 CDN 链路通常分成两段：
第一段是客户端到 CDN。用户访问的是：
虽然 DNS 最终返回的是 CDN 边缘节点 IP，但 URL 里的域名仍然是 static.example.com。因此 TLS 握手时，CDN 节点必须返回匹配 static.example.com 的证书。浏览器验证通过后，才会继续发送 HTTP 请求。
第二段是 CDN 到源站，叫回源协议。可以配置 HTTP 回源或 HTTPS 回源。为了避免外部链路被窃听或篡改，生产环境更推荐 HTTPS 回源。
两类证书的区别如下：
如果配置为：
用户地址栏仍然显示 HTTPS，但 CDN 到源站这一段不是加密链路。这种方式配置简单，但不属于端到端加密，生产环境通常更推荐 HTTPS 回源。
这里还要注意：如果 CDN 终止 TLS，那么 CDN 节点可以看到明文 HTTP 内容，然后再决定是否缓存、压缩、改写或回源。因此涉及高度敏感的数据时，需要谨慎评估 CDN 的角色、配置和合规要求。
CDN 常见安全配置包括：
- HTTPS 证书和 TLS 配置。
- HTTP 自动跳转 HTTPS。
- Referer 防盗链。
- Token 鉴权、防盗链签名 URL。
- IP 黑白名单。
- 频率限制。
- WAF 规则。
- DDoS 清洗。
这些能力可以把一部分攻击流量挡在源站之前，但不能替代应用自身的权限校验和输入校验。
CDN 在实际项目中的应用
静态资源加速
这是最典型的前端场景。构建工具会把资源打包成带哈希的文件：
部署时把这些文件上传到对象存储或静态服务器，再由 CDN 分发。页面中引用 CDN 地址：
推荐策略：
- 带内容哈希的 JS、CSS、图片设置长期缓存，例如
max-age=31536000, immutable。 - HTML 入口文件不要长期强缓存，避免用户一直拿到旧资源引用。
- 发布新版本时生成新文件名，而不是覆盖旧文件。
图片和媒体分发
图片、音视频体积大，对带宽和加载体验影响明显。CDN 常用于：
- 图片压缩和格式转换，例如 WebP、AVIF。
- 根据设备宽度返回不同尺寸图片。
- 视频分片分发。
- 下载限速和防盗链。
图片资源通常适合 CDN 缓存，但用户头像、私有图片、付费内容需要做好鉴权、防盗链或私有访问控制。
第三方库托管
有些项目会通过 CDN 引入 React、Vue、Lodash 等公共库：
这种方式可以减少自身构建体积，也可能利用公共缓存。但它也有风险：
- 第三方 CDN 故障会影响页面可用性。
- 版本地址如果不固定，可能引入不可控变更。
- 需要考虑 SRI 完整性校验和 CSP。
- 在现代工程化项目中，核心依赖通常更推荐打包进自己的构建产物，或使用受控的私有 CDN。
灰度发布与多环境资源
CDN 可以配合构建版本号、路径前缀或边缘规则做灰度。例如：
也可以通过不同域名区分环境：
但要注意缓存隔离，避免测试资源被线上页面引用，或线上缓存污染测试环境。
常见问题与排查思路
为什么资源更新后用户仍然看到旧版本
常见原因：
- HTML 被强缓存，仍然引用旧 JS 和 CSS。
- CDN 节点缓存未刷新。
- 浏览器缓存仍然有效。
- 文件名没有内容哈希，覆盖发布导致缓存不可控。
- 中间代理或 Service Worker 还有缓存。
排查时可以看响应头中的 Cache-Control、Age、ETag、Last-Modified、Via、X-Cache 等字段。
为什么 CDN 命中率很低
常见原因：
- URL 带大量随机参数。
- 缓存时间太短。
- 响应头禁止缓存。
- 动态资源被误接入 CDN 但无法共享缓存。
- 不同请求头、Cookie 导致缓存键过细。
- 资源访问分散，没有形成热点。
为什么访问 CDN 反而变慢
可能原因：
- DNS 调度不准确。
- 用户到节点网络质量差。
- 节点缓存未命中，经常回源。
- 源站回源链路慢。
- HTTPS 握手、证书链、HTTP/2/HTTP/3 配置不合理。
- 资源本身体积过大，没有压缩或图片优化。
CDN 加速的是链路和缓存，不会自动修复资源过大、接口慢、前端渲染慢等问题。
CDN 会不会缓存错误响应
可能会，取决于 CDN 配置和响应头。某些 CDN 可以配置是否缓存 404、301、302、500 等响应，以及缓存多久。错误缓存有时能减少源站压力，但也可能放大一次发布错误的影响，所以需要谨慎设置。
面试中的标准回答
如果面试官问“CDN 是什么，它的工作原理是什么”，可以这样回答：
CDN 是内容分发网络，它通过在各地部署边缘节点，把静态资源或可缓存内容分发到离用户更近的位置。用户访问 CDN 域名时，DNS 或调度系统会根据地域、运营商、节点健康和负载等因素返回合适的边缘节点 IP。浏览器与该节点建立连接并请求资源，如果节点缓存命中，就直接返回；如果没有命中或缓存过期，节点会向源站回源，拿到资源后按缓存策略保存，再返回给用户。CDN 的主要价值是降低延迟、提升访问速度、减少源站压力，并增强可用性和安全防护。
如果继续追问“CDN 的 CNAME 配在哪里”，可以这样回答：
通常配置在业务加速域名所属 DNS 区域的权威 DNS 中。例如 static.example.com 通常只是 example.com 区域下的一条记录，所以是在 example.com 的权威 DNS 里配置 static.example.com CNAME static.example.com.cdnvendor.net。只有当 static.example.com 被单独委派成一个子区域时，才会由它自己的权威 DNS 管理。
如果继续追问“请求 CDN 资源的链路”，可以按顺序回答：
- 浏览器解析页面，发现需要加载 CDN 资源。
- 对 CDN 域名做 DNS 解析。
- DNS 通过 CNAME 进入 CDN 调度系统。
- 调度系统返回合适的边缘节点 IP。
- 浏览器和 CDN 节点建立 TCP/TLS 连接。
- 浏览器发送 HTTP 请求。
- CDN 节点检查缓存。
- 命中则直接返回。
- 未命中则回源拉取资源。
- CDN 缓存资源并返回给浏览器。
总结
CDN 的本质是“分布式边缘缓存 + 智能调度 + 回源机制”。它通过把资源放到离用户更近的位置，减少网络距离、提高响应速度，并把大量重复请求挡在源站之外。
在实际项目中，CDN 最常用于静态资源、图片、音视频和下载文件分发。前端工程里尤其要注意资源哈希、缓存头、HTML 缓存策略、刷新预热、HTTPS 配置和缓存键设计。CDN 用得好，可以显著提升加载体验；用得不谨慎，也可能带来旧资源、缓存污染、隐私数据泄露和排查复杂度上升等问题。