缓存

缓存层级

Web 请求的缓存分两层：浏览器缓存（客户端本地）和 CDN 边缘缓存（代理节点）。两层独立生效、独立过期——清了边缘缓存不影响浏览器缓存，浏览器 TTL 未过期时用户本地仍会看到旧内容。理解这一点是排查"更新了但用户看不到"问题的前提。代理/边缘相关的整体架构与安全机制见网络与流量安全。

浏览器缓存

浏览器缓存由响应头（Cache-Control/Expires）声明的 TTL 控制，TTL 内浏览器直接读本地副本，不发出请求。这是一个加载速度与更新时效的权衡：TTL 越长加载越快、更新越慢。

常见实践：

静态资源：长 TTL 配合文件名哈希——内容变则文件名变，天然绕开旧缓存
HTML 入口：短 TTL，保证用户及时拿到新入口，再由入口引用带哈希的新资源

CDN 代理节点把源站响应缓存下来，后续相同请求直接由边缘返回，不回源。缓存范围由策略决定：是否缓存带查询字符串的资源、按哪些维度区分缓存副本（缓存键）——默认只按 URL 区分，若同一 URL 会因设备类型、地域等返回不同内容，就需要在缓存键里加上这些维度，否则不同用户会拿到同一份副本。只有经过代理的流量才有边缘缓存，直连源站的请求不受影响。代理侧的缓存清理与 DDoS/Bot 防护配合方式见流量安全。

分层缓存

大型 CDN 内部还有层级：边缘节点未命中时先查区域中心节点，仍未命中才回源。这样大多数请求止步于 CDN 内部，显著降低源站的带宽压力和负载。

一次请求的完整查找路径：

缓存失效

失效有两条路径：

方式	作用范围	时机
主动清除（purge）	仅边缘缓存	立即生效
自然过期	浏览器 + 边缘	等 TTL 耗尽

由此得出标准更新流程：发布新版本 → 清除边缘缓存 → 浏览器侧靠 TTL 过期或文件名哈希更新。主动清除会暂时增加回源压力，全站大规模清除后短时间内源站负载会升高。

清除缓存 ≠ 用户立刻看到新版

清除只作用于边缘节点，浏览器缓存不受影响；在浏览器 TTL 过期前，部分用户仍会看到旧内容。

调试时用开发模式

调试场景下可以让代理临时绕过缓存直接回源（各 CDN 都有类似"开发模式"的开关）。注意两点：绕过的流量全部打到源站，负载会上升；绕过不等于清除，关闭后旧缓存仍在，必要时仍需手动清。

源站故障兜底

源站不可用时，代理可以用陈旧副本兜底：从本地存储或网页存档（如 Wayback Machine）提供上一次的页面快照。这是用时效性换可用性的降级手段，只保证"能看到"，不保证"是最新的"。