Webpack中CSS文件名加contenthash的关键配置必须用[contenthash]，通过MiniCssExtractPlugin抽离CSS并配合HtmlWebpackPlugin自动替换HTML中的link标签，Vite需确保模块化引入或插件接管HTML，CDN回源和服务端Cache-Control头必须正确配置以避免404和缓存失效。
Webpack 项目中 CSS 文件名加 contenthash 的关键配置
必须用 [contenthash]，不能用 [hash] 或 [chunkhash]。前者基于文件内容生成，CSS 内容不变则哈希不变；后两者要么全项目联动变化，要么因 JS 引用导致 CSS 哈希误变。
MiniCssExtractPlugin 是核心：它把 CSS 从 JS 中抽离成独立文件，才能单独应用 [contenthash]。没它，CSS 会随 JS 打包进 .js 文件，根本没法独立缓存控制。
-
MiniCssExtractPlugin.filename = '[name].[contenthash:8].css'—— 控制输出文件名 -
HtmlWebpackPlugin必须启用，且确保它读取的是 Webpack 编译后的 asset 清单，自动把 HTML 中的<link href="main.css">替换为<link href="main.a1b2c3d4.css"> - 若用了
@import，比如main.css里写了@import "base.css"，构建工具必须能解析并重写该路径——Vite 默认支持，Webpack 需配css-loader的url: true和importLoaders
Vite 项目默认就带哈希，但得确认是否生效
Vite 在生产构建时默认对 CSS 输出带 [hash]（实际是 contenthash 衍生），但容易被忽略的点是：如果你在 index.html 里手写了 <link rel="stylesheet" href="/css/main.css">，这个路径不会被自动替换——Vite 只重写通过 import 或 css 模块方式引入的资源。
- 务必改用模块化引入：
import './style.css'，或让 Vite 插件接管 HTML（如vite-plugin-html） - 检查构建产物
dist/目录下 CSS 文件名是否含哈希，例如index.abc123.css；如果还是style.css，说明build.rollupOptions.output.assetFileNames被覆盖或未匹配到 CSS 类型 - 推荐显式配置：
assetFileNames: 'assets/[name].[hash:8].[ext]'，并确保public/下的静态 CSS 不走此规则（否则不被哈希）
CDN 回源失败导致 404 的典型原因
文件名带哈希了，HTML 也引用对了，但用户打开页面控制台报 GET https://cdn.example.com/assets/main.a1b2c3d4.css 404——问题不在前端代码，而在 CDN 回源配置。
立即学习“前端免费学习笔记（深入）”；
- CDN 控制台「回源路径重写」规则可能把
.a1b2c3d4.css截断成.css，或正则误删哈希段，结果源站收到的是/assets/main.css，而真实文件是/assets/main.a1b2c3d4.css - Nginx 源站若配了
location ~ \.css$但没放开点号和字母数字组合，会拒绝.a1b2c3d4.css这类文件名，返回 403 或 404 - 上线前必须用
curl -I https://cdn.example.com/assets/main.a1b2c3d4.css实测，看返回是不是200和正确的Content-Type: text/css
服务端 Cache-Control 头必须配合哈希文件
文件名变了，但响应头仍是 Cache-Control: max-age=600，CDN 仍可能只缓存 10 分钟；更糟的是，如果头里漏了 immutable，浏览器每次访问都会发条件请求（If-None-Match），失去哈希缓存的最大优势。
- 对所有带哈希的静态资源（
.js、.css、.woff2等），源站应返回：Cache-Control: public, max-age=31536000, immutable - HTML 文件必须反其道而行：
Cache-Control: no-cache或max-age=0，否则用户永远加载不到新哈希的入口 - CDN 控制台不要开启「强制覆盖源站缓存头」，尤其避免全局设成
max-age=3600——这会直接废掉immutable的语义
