CDN上CSS缓存不更新的根本原因是HTTP缓存头（Cache-Control/Expires）配置不当，导致浏览器复用旧资源；应采用内容哈希文件名、正确配置CDN缓存键（含Accept-Encoding）、避免HTTP/2 Push，预加载仅限关键CSS并配onload回退。
CDN上CSS缓存不更新，页面还是旧样式
浏览器死死攥着旧的 style.css，哪怕你已在CDN上替换了文件，用户刷新也看不到变化——这不是CDN没同步，是HTTP缓存头在拦路。
关键在响应头里的 Cache-Control 和 Expires。CDN默认可能设了长缓存（比如 1 年），而你又没改文件名或加版本参数，浏览器根本不会重新拉新内容。
- 上线前必须确认 CDN 的缓存规则：对
.css资源是否设置了Cache-Control: public, max-age=31536000这类强缓存 - 若用的是版本号路径（如
/css/app.v2.3.css），确保构建工具真生成了新文件名，且 HTML 中引用的href同步更新 - 若用查询参数（如
style.css?v=20240520），注意部分CDN（如 Cloudflare 免费版）默认忽略 query string 缓存键，需手动开启Cache by URL with query string
如何安全地强制刷新CSS而不影响用户体验
不能一上线就全局清CDN缓存——那会触发大量回源，压垮源站；也不能靠用户硬刷 Ctrl+F5，没人会这么做。
真正可控的方式是「文件内容哈希 + 不变URL」：构建时根据 CSS 内容生成唯一哈希，嵌入文件名，例如输出 main.a8f3b2d.css。这样每次内容变，URL 就变，浏览器自然走新缓存。
立即学习“前端免费学习笔记（深入）”；
- Webpack 用户检查
output.filename是否含[contenthash]（不是[hash]），Vite 默认已启用assetsInlineLimit外的哈希命名 - 避免用时间戳（
?t=1716234567）做版本号：构建并发时可能产出相同时间戳，导致缓存误命中 - HTML 中引用必须由构建流程注入，禁止手写静态
v=参数——否则 JS/CSS 版本不同步，极易引发样式错乱
CDN缓存头配置不当导致本地调试失效
本地开发时开代理指向CDN域名，结果改完CSS保存，浏览器仍加载CDN返回的旧缓存——因为CDN把本地请求也按生产规则缓存了。
根源在于 CDN 没区分环境。它只看请求 URL 和 Host，不识别你是不是在 localhost:3000 上调试。
- 开发阶段建议绕过CDN：在本地 hosts 或代理配置中，将 CSS 域名直连源站（如
static.example.com → 127.0.0.1:8080） - 若必须走CDN调试，可在 CDN 规则里加条件：当请求头含
Origin: http://localhost或 Cookie 含dev=true时，返回Cache-Control: no-cache, must-revalidate - 切勿在生产环境响应头里写
Cache-Control: no-store——这会让CDN完全不缓存，失去CDN意义
HTTP/2 Push 已被主流CDN弃用，别再依赖它预加载CSS
有些老文档还提“用 Link: <style.css>; rel=preload; as=style 推送CSS”，但 Cloudflare、AWS CloudFront、阿里云全站加速等早已关闭 HTTP/2 Push 支持，且 Chrome 96+ 已移除该功能。
现在唯一可靠预加载方式是 HTML 中显式写 <link rel="preload" href="main.css" as="style">，并确保该标签在 <head> 顶部、早于其他资源解析。
- Preload 只是提前发起请求，不执行；记得配
onload补充rel="stylesheet"，否则样式不生效 - CDN 对
preload请求仍走常规缓存逻辑，所以它依然受前面说的Cache-Control控制 - 不要对所有CSS都 preload：只有首屏关键样式才值得，非关键CSS用普通
link即可，避免抢占带宽
Accept-Encoding？如果没包含，gzip 和 brotli 响应可能混用，导致 CSS 解析失败——这个细节连很多CDN控制台都不明显提示。 
