2026-10-29 · 技术
发版后用户还看到旧页面，多半不是CDN坏了，而是缓存层级比你想象的多。本文讲清边缘、中间层与浏览器缓存的关系，URL、目录、全站三种刷新的适用场景，以及从设计上避免依赖刷新的做法。
发版之后最常见的投诉是：我这边还是旧页面。运营看到的是旧价格，测试看到的是旧按钮，而你在服务器上确认文件已经换了。 这不是 CDN 坏了，多数情况是缓存层级比你想象的多。 一次请求从用户到源站，中间至少有四层可能留下旧内容：浏览器本地缓存、CDN 边缘节点、CDN 的中间层（父层或回源层），以及源站前面的反向代理或对象存储。你刷新了一次，只代表其中一层收到了指令。 从响应头能看出命中在哪一层。看 Age 判断内容在边缘放了多久，看 X-Cache、CF-Cache-Status 这类字段判断是命中还是回源，再看 Via 里有没有中间层。带着这些信息去提工单，比一句“我这边没更新”有效得多。 三种刷新方式，用错场景就会出问题。 按 URL 刷新最精准，适合单个页面、单张图片、一个 JS 文件。提交后一般几十秒到几分钟生效，量小、风险低，日常发版优先用它。 按目录刷新适合整站改版，比如活动页整体换版。要注意目录前缀是包含关系，刷 /act/ 会把下面所有文件一起刷掉。 全站刷新是核武器，只在极端情况用。它会让所有节点同时回源，源站瞬间承受全网请求，带宽小的机器很容易被打挂。真要用，先确认源站能扛住，或者配合预热。 比刷新更重要的是在设计阶段就别依赖刷新。 静态资源带文件指纹，app.2f3a91.js 这种命名，内容变了 URL 就变，天然不需要刷新，还可以设一年长缓存；HTML 入口给短缓存，比如一到五分钟，保证改版能快速生效；接口类请求明确 no-cache 或短 TTL，别让价格、库存被缓存住。 还有一个常被忽略的点：发版时的灰度。先刷一个测试域名或一部分节点，确认页面正常再全量，能避免刷完发现样式崩了、全网用户都看到的尴尬。 CDN 缓存不是玄学，搞清楚层级、看懂响应头、用对刷新方式，大部分“没更新”的问题十分钟内能定位。 如果你的站点同时面向国内和东南亚用户，加速IDC 的 CDN 加速覆盖东南亚 12 个节点，支持按 URL 与目录刷新，配合弹性源站带宽，发版时更从容。
