根本解法是让CSS文件URL随内容变化：Webpack需配置contenthash并用mini-css-extract-plugin；Vite需在rollupOptions中设assetFileNames含[hash]；HTML中禁用手写link，改用JS import；CDN/Nginx需配immutable缓存策略。
Webpack 构建后 CSS 文件没变但浏览器还在用旧样式
这是典型的缓存问题：HTML 中引用的 main.css 路径没变，浏览器直接从缓存加载，压根没发请求。构建工具不改文件名或 URL，光靠刷新没用。
根本解法不是清缓存，而是让「URL 变」——每次内容变化，URL 就得不同。Webpack 默认不这么做，得手动配。
- 确保
output.filename和output.chunkFilename含[contenthash]，例如main.[contenthash:8].css - CSS 提取必须用
mini-css-extract-plugin，不能用style-loader（后者把样式塞进 JS，哈希打不到 CSS 本身） - HTML 插件（如
html-webpack-plugin）要启用inject: true，它才会自动把带哈希的<link>写进 HTML
Vite 项目里 CSS 更新了但页面还是旧样式
Vite 开发时热更新快，但生产构建默认不加哈希到 CSS 文件名。如果你用 vite build 出来仍是 style.css，CDN 或代理层缓存就会卡住旧版本。
解决方式和 Webpack 不同：Vite 没有内置 CSS 哈希命名，得靠 build.rollupOptions.output.entryFileNames 和 chunkFileNames 手动控制，且必须覆盖 CSS 输出逻辑。
立即学习“前端免费学习笔记（深入）”；
- 在
vite.config.ts中配置：build.rollupOptions.output.assetFileNames设为"assets/[name].[hash].css" - 注意
[hash]是文件内容 hash，不是[contenthash]（Rollup 里统一叫[hash]） - 如果用了
cssCodeSplit: true（默认开启），得同时配entryFileNames和chunkFileNames，否则 JS 里的 CSS 引用仍可能无哈希
HTML 中手动写的 没被构建工具接管
哪怕 Webpack/Vite 配好了哈希，只要你在 HTML 里硬写 <link href="static/css/app.css">，构建工具就完全无视这行——它只处理 JS 中 import './app.css' 的路径。
这种写法等于绕过整个资源指纹体系，是线上样式不更新最隐蔽的原因之一。
- 删掉所有手写的
<link>标签，改用 JS import：比如在入口main.ts里写import './styles/app.css' - 如果必须保留 HTML 中的 link（如第三方皮肤 CSS），那就得自己拼哈希：用构建插件读取输出 manifest.json，把
app.css替换成app.a1b2c3d4.css - 检查打包产物目录，确认最终 HTML 里的
href值是否含哈希——这是唯一可信依据，别信本地开发时的表现
CDN 或 Nginx 缓存了带哈希的 CSS 文件
文件名带哈希了，但用户第一次访问时 CDN 缓存了那个哈希文件，后续你又发新版、生成新哈希，CDN 却没及时回源，结果新 HTML 引用新哈希，CDN 却返回 404 或旧内容。
这不是前端构建问题，是部署链路断了。哈希只是第一步，缓存策略必须同步升级。
- 确保 CDN 对
.css文件设置短缓存（比如max-age=31536000是错的），正确做法是max-age=31536000+immutable（告诉浏览器“这个 URL 永远不变”，可安全强缓存） - Nginx 配置里避免全局
expires 1y，应按后缀区分：location ~ \.css$ { expires 1y; add_header Cache-Control "public, immutable"; } - 上线后立刻验证：打开新 HTML，看 Network 面板里 CSS 请求是否 200，Response Headers 是否含
Cache-Control: public, immutable
哈希值本身不解决缓存，它只是让「缓存失效」变得可控；真正起作用的是构建、注入、部署、CDN 四个环节全部对齐。漏掉任意一环，用户看到的都可能是上周的按钮颜色。
