带 hash 的 JS/CSS、图片、字体、视频、公开配置——读多、不因用户变化、能容忍按 TTL 或发布刷新。多地区用户受益最大。
数据与服务 · 运行与可靠性
内容分发网络CDN
CDN 把静态资源复制到离用户很近的边缘节点：请求先问边缘，命中就近秒回，没命中才回远端源站并缓存一份；发布后用 hash URL 或精确 purge 让用户看到新版本。
试一遍：就近命中、回源与失效
选一个地区和一个资源，点「请求资源」。第一次从未命中（MISS）开始——回到远端源站取回，并写进该地区的边缘；再点一次同地区同资源就命中（HIT）。换地区或换资源都是新 cache-key，要重新回源；动态接口永不缓存。
请求先到就近的边缘节点：命中就秒回，没命中才回远端源站、再写一份进边缘。 换地区或换资源都是新 cache-key，要重新回源一次；动态接口不缓存。
边缘节点（按地区）当前资源：app.8f3.js
北京直连源站 160 ms○未缓存
纽约直连源站 220 ms○未缓存
伦敦直连源站 260 ms○未缓存
源站（origin）唯一真源；MISS 才被访问
请求来源
暂未请求
暂无请求
请求 0 次 · 命中 0 次
延迟对照 · 北京
直连源站（无 CDN）160 ms
边缘命中 HIT12 ms
边缘未命中 MISS160 ms
没有 CDN 时，每次请求都像 MISS 一样跑回源站；命中省下的就是这中间的距离。
选好地区和资源，点「请求资源」。北京边缘还空着，第一次会是 MISS：回到远端源站取回，再写进北京边缘。
CDN 要盯住的几件事
面板里已经见过，这里只命名：边缘、命中、回源、cache-key、失效、不缓存动态。
- 边缘节点就近
请求先到离用户近的边缘，命中就直接返回；距离省下来的就是延迟。面板里三个地区各有自己的边缘格。
- 命中 / 未命中
命中（HIT）= 边缘有这把 key，就近秒回；未命中（MISS）= 回源站取，再写进边缘。命中率越高，回源越少。
- cache-key 按地区和 URL 分
换地区、换资源都是新 key——面板里切到纽约，同一张 app.8f3.js 又是未命中。缓存不是全局一份，是每把 key 各算。
- 显式失效（purge）
发布紧急修复时按 key 清掉旧版本，下一次请求重新回源取新内容。purge 是精确的，别拿「全站 purge」当发布流程。
- 动态内容不缓存
购物车、个人订单、实时库存按用户实时生成，边缘命中反而给错数据。面板里 GET /api/cart 每次都回源。
什么时候用 CDN
面向多地区用户的静态资源最适合；个性化 / 实时内容不适合。
购物车、个人资料、实时余额与库存等需要请求级新鲜的响应；以及源站计算本身慢（DB 慢、渲染慢）——CDN 只搬副本，不加速计算。
怎么用才不出错
从接入到发布刷新的最短路径。
- 把静态资源域名 CNAME 到 CDN；源站保留唯一真源，供 MISS 回源。
- 按类型设 Cache-Control：hash 资源 max-age 大 + immutable；HTML 短 TTL；图片按尺寸格式。
- 发布用新 hash URL 让新版本自然绕过旧缓存；紧急情况按 key purge，不全站清。
- 监控命中率与回源率；命中率低就查 Cache-Control、key 和 TTL 是否设错。
同一站点，两种缓存策略
正例靠 URL 变化自然更新；反例把 HTML 也长缓存，发布后用户看到旧页面。
app.8f3.js 把内容版本写进文件名。边缘和浏览器都敢设一年长缓存；发布新版会生成 app.9a1.js 这个新 URL，新入口自然指向新资源，旧缓存不挡路，不用全站 purge。
差异：靠 URL 变化让新版本自然绕过旧缓存。index.html 被边缘长缓存。你发布了新版本，可用户拿到的还是旧入口 HTML，里面引用的还是旧 hash 的 JS——页面看起来「永远不更新」。purge 全站又会让所有用户瞬间回源，压垮源站。
差异：HTML 用短 TTL 或发布时精确 purge 入口；hash 资源才长缓存。快速自测
发布新版首页后，有用户过了半小时才看到新内容。最可能漏了哪一步？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。