浏览器缓存行为由服务器及cdn返回的http缓存头控制；cdn通过配置cache-control、etag等响应头，结合资源类型差异化策略（如哈希资源设immutable、html设no-cache）、回源防护机制（stale-while-revalidate、cache locking）及持续验证优化，提升缓存命中率并降低源站压力。
浏览器缓存本身由客户端控制，但它的行为高度依赖服务器（含 CDN）返回的 HTTP 缓存响应头。CDN 节点作为中间层，可通过配置缓存策略，决定哪些资源被缓存、缓存多久、是否校验新鲜度，从而显著减少回源请求，降低源站压力。
关键缓存响应头在 CDN 中的配置逻辑
CDN 通常允许你在控制台或配置文件中为不同路径/文件类型设置响应头。核心是正确设置以下字段：
-
Cache-Control：优先级最高，明确指定缓存行为。例如：
public, max-age=31536000, immutable（适用于带哈希指纹的静态资源）；public, max-age=3600（通用 JS/CSS）；no-cache（强制校验，需配合 ETag 或 Last-Modified） -
ETag / Last-Modified：CDN 需透传这些头给浏览器，并在收到条件请求（
If-None-Match或If-Modified-Since）时向源站发起验证。启用可实现“缓存不失效但按需更新” -
Expires：HTTP/1.0 兼容字段，语义与
max-age类似，但建议以Cache-Control为主，避免时间基准不一致问题
按资源类型差异化配置 CDN 缓存规则
“一刀切”的缓存策略容易引发资源更新不生效或频繁回源。应结合资源变更频率和部署方式分级处理：
-
带内容哈希的静态资源（如
app.a1b2c3.js、logo.d4e5f6.png）：设Cache-Control: public, max-age=31536000, immutable。CDN 可长期缓存，永不回源（除非 TTL 到期或手动刷新） -
无哈希的通用资源（如
vendor.js、common.css）：设Cache-Control: public, max-age=86400, must-revalidate，每日回源一次校验，平衡一致性与性能 -
HTML 页面：一般禁用强缓存，设
Cache-Control: no-cache, must-revalidate，确保每次访问都向 CDN 请求最新版本；CDN 可开启“边缘 HTML 缓存 + 小 TTL（如 60s）+ 回源校验”，兼顾首屏速度与实时性
CDN 回源策略与缓存穿透防护
即使缓存命中率高，突发流量或缓存失效仍可能导致大量并发回源请求压垮源站。CDN 层需配合以下机制：
-
Stale-While-Revalidate：配置
stale-while-revalidate=86400，允许 CDN 在缓存过期后仍提供旧资源，同时异步刷新，避免用户等待回源 - 缓存锁（Cache Locking）：当多个请求同时触发同一资源回源时，CDN 只放行一个回源请求，其余等待其结果并复用，防止“缓存雪崩”式打源
-
主动预热 & 缓存刷新：发布新版本前，通过 CDN API 提前预热关键资源；更新后仅刷新对应路径（如
/js/app.*.js），而非全站 purge
验证与持续优化建议
配置不是一劳永逸，需结合真实请求链路持续观测：
- 用 Chrome DevTools 的 Network 面板检查资源响应头，确认 CDN 是否按预期注入了
Cache-Control和X-Cache（如HIT/MISS/STALE） - 在 CDN 后台查看缓存命中率报表（理想值 >95% 对于静态资源）；关注回源带宽和请求数突增时段
- 对 JavaScript 资源，注意
immutable头仅适用于内容不变的文件；若误用于动态生成的 JS（如含时间戳），会导致更新不可见
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
