应采用文件名哈希方案，即构建时生成带内容哈希的CSS文件（如index.abc123.css）并自动更新HTML中对应link引用，同时确保CDN/Nginx按后缀精细化缓存、避免覆盖，方可彻底解决样式更新不生效问题。
为什么改了 CSS 文件，页面还是旧样式
浏览器缓存了旧的 style.css 文件，即使你本地已更新、服务器也重新部署了，用户访问时仍可能加载缓存版本。这不是代码写错了，而是 HTTP 缓存策略在起作用——尤其当响应头里有 Cache-Control: max-age=31536000 或 Expires 远期时间时，浏览器会直接复用本地副本，根本不发请求。
常见现象包括：开发者工具 Network 面板里 style.css 状态是 200 (from memory cache) 或 304，但预览内容明显不是最新；强制刷新（Ctrl+F5）后正常，但普通刷新或新标签页仍不生效。
手动清理缓存只治标，不适合线上环境
清浏览器缓存、禁用缓存（DevTools → Network → ☑️ Disable cache）、硬重载（Shift+Cmd+R）确实能让当前页面变新，但这对真实用户无效。不能要求用户都去按组合键，也不能靠“等缓存过期”来交付功能。
- 开发阶段可临时用
Cache-Control: no-cache响应头，但上线必须撤掉 - 本地测试时建议用无痕窗口或服务端加随机查询参数（如
style.css?v=123），但该方式不推荐用于生产 - 某些 CDN 会忽略查询参数做缓存（比如只认路径），导致
?v=xxx失效
文件名哈希 + 构建工具自动注入才是可靠方案
现代前端构建（Webpack/Vite/Rollup）默认会在输出 CSS 文件名中嵌入内容哈希，例如从 index.css 变成 index.abc123.css。只要内容变化，哈希就变，URL 就不同，浏览器自然视为新资源并重新请求。
立即学习“前端免费学习笔记（深入）”；
关键点在于：HTML 中引用的 <link href="..."> 必须同步更新为新文件名，不能手写死。
- Webpack 用户确保
HtmlWebpackPlugin启用inject: true，它会自动把生成的带哈希的 CSS 路径写入 HTML - Vite 用户无需额外配置，默认启用
build.rollupOptions.output.entryFileNames和assetFileNames的哈希命名 - 若用纯静态 HTML + 手动部署，可用脚本替换 HTML 中的
href值，但容易出错，不推荐
CDN 和反向代理也要检查缓存配置
即使源站返回了正确的新文件和 Cache-Control: public, max-age=31536000，CDN（如 Cloudflare、阿里云 CDN）或 Nginx 反向代理仍可能缓存旧版本。它们通常按 URL 缓存，所以带哈希的文件名能绕过这个问题；但如果用了查询参数或路径未变，就得手动刷新 CDN 缓存或调整缓存规则。
- Nginx 示例：确认没有全局
expires 1y覆盖了 CSS 资源，建议按后缀精细化控制：location ~* \.css$ { expires 1h; } - Cloudflare：检查 “Caching Level” 是否为 “Standard”，并确认 “Cache Everything” 规则没误匹配 CSS 路径
- 发布后快速验证：用
curl -I https://yoursite.com/static/index.abc123.css查看CF-Cache-Status是否为HIT或MISSED，避免假性生效
最常被忽略的是 CDN 缓存穿透失败——你以为文件名变了，结果构建产物被上传到错误路径，或者 HTML 引用的仍是旧哈希名。上线后第一件事，别只看页面效果，先打开 Network 面板，点开 CSS 请求，核对响应内容和 URL 是否真匹配你刚部署的文件。
