浏览器对CSS文件启用强缓存，服务器返回Cache-Control: max-age=31536000时，即使HTML更新，浏览器仍直接读取本地旧副本；需通过文件名哈希、CDN缓存策略分离及Service Worker版本控制等多层协同解决。
link标签引用的CSS文件为何改了不生效
浏览器对引入的CSS文件默认启用强缓存，哪怕HTML已更新，旧CSS仍从磁盘读取——你看到的“没变化”，大概率不是代码没改，而是浏览器根本没重新请求那个文件。
关键点在于：Cache-Control响应头由服务器控制，不是HTML里写个meta就能覆盖的。比如服务器返回Cache-Control: max-age=31536000，浏览器就会缓存一年，期间所有href="style.css"都直接走本地副本。
- 检查方式：打开开发者工具 → Network → 刷新页面 → 找到你的CSS请求 → 看Headers里的
Response Headers部分，重点盯Cache-Control和ETag - 常见陷阱：本地双击
file://打开HTML时，浏览器可能忽略缓存头，但部署到Nginx/Apache后立刻暴露问题 - 开发阶段可临时加查询参数破缓存，例如
href="style.css?v=20260819"，但上线必须用构建工具自动注入哈希
如何让CSS更新强制生效（非开发环境）
靠手动改v=参数不可持续，真正可靠的方案是让文件名本身带变化——浏览器把不同文件名视为不同资源，天然绕过缓存。
构建工具（如Vite、Webpack）会生成类似style.a1b2c3.css的文件，并自动更新HTML中href值。你只需确保：
立即学习“前端免费学习笔记（深入）”；
- HTML中
href确实被替换成带哈希的路径，而不是还留着style.css - 服务器配置允许访问带哈希的静态文件（Nginx默认支持，无需额外设置）
- CDN缓存策略排除
.html，但允许.css走长缓存——二者必须分开配置
Service Worker会干扰CSS缓存更新吗
会，而且干扰得很彻底。一旦注册了Service Worker，它就接管所有fetch请求。如果你在fetch事件里写了event.respondWith(cache.match(event.request))却没做版本校验，那浏览器永远返回旧缓存，连Ctrl+F5都无效。
典型症状：Network面板里CSS请求显示from ServiceWorker，但响应内容还是上上周的。
- 解决方法：在
install事件中用新cache名称（如caches.open('styles-v2')），并在activate中清理旧cache - 别在
fetch里无差别匹配：只对event.request.destination === 'style'的请求尝试缓存，其他走fetch(event.request) - 调试时可在Application → Service Workers里勾选
Update on reload，但上线必须靠代码逻辑控制
为什么禁用浏览器缓存后CSS还是没变
说明问题不在浏览器层，而在更上游：CDN、反向代理或源站HTTP头。尤其当index.html本身被缓存时，里面写的href="style.css"压根没机会更新。
排查顺序必须是：先确认HTML是否最新 → 再看CSS请求是否发出 → 最后查CSS内容是否正确。很多人卡在第一步，却去翻CSS选择器。
- 用
curl -I https://yoursite.com/index.html看响应头，若Cache-Control含max-age且值很大，问题就在HTML缓存 - 纯静态SPA（如Vue/React单页应用）的
index.html应设为Cache-Control: no-cache, must-revalidate，而非no-store - Cloudflare等CDN常把
/路径默认缓存，需单独添加规则：缓存级别设为Bypass或Standard，并排除index.html
