开发环境类名哈希不一致导致样式部分失效，根源是css-loader默认用基于路径的[hash]而非内容哈希，造成热更新时新旧类名共存；应分环境配置：开发禁用哈希、生产启用[contenthash]，并规范作用域边界与插件输出。
开发环境类名哈希不一致，导致样式“部分失效”
这不是 CSS 内容没更新，而是热更新时 css-loader 用的哈希策略和生产环境不统一：开发默认用 [hash]（基于模块路径），改个文件位置或引入顺序，button_abc 就可能变成 button_def，旧样式残留，新旧类名共存。
解决思路不是强行在开发环境用 contenthash（style-loader 不支持），而是分环境控制：
- 开发环境禁用哈希：
localIdentName: '[name]__[local]'，靠文件名 + 原始类名隔离，配合命名规范防冲突 - 生产环境启用内容哈希：
localIdentName: '[name]__[local]--[contenthash:base64:5]'，确保内容不变则类名不变 - 别在
postcss.config.js里重复配postcss-modules，它和css-loader的 modules 功能重叠，容易导致哈希生成两次
哈希太长或语义丢失，调试困难
BEM 类名如 button__text 被转成 buttonText 或纯哈希 _1a2b3c，就断掉了可读性和工具链支持（比如 stylelint-selector-bem-pattern 报错）。
关键配置必须显式写全：
立即学习“前端免费学习笔记（深入）”；
-
modules: { mode: 'local' }（Webpack 5+ 必须写enabled: true或对象形式，不能只写true） -
localsConvention: 'camelCaseOnly'——保留双下划线结构，button__text→button__text，不是buttonText -
localIdentName至少含[name]和[local]，例如'[name]__[local]--[hash:6]'，否则你根本不知道btn_8e3f2a来自哪个文件
全局类被误加哈希，打包体积暴涨
没包裹 :global() 的第三方样式（如 .el-button）、CSS Reset、工具类，全被当成局部作用域处理，css-loader 不仅重命名，还在 JS Bundle 里塞入大量 locals 映射逻辑，动辄多出几十 KB。
真正要做的不是关 modules，而是精准控制作用域边界：
- 所有非模块化 CSS 必须显式声明：
:global(.el-button) { ... }或:global(*) { ... } - 禁用无谓的导出：
exportLocalsConvention: false（除非你真需要在 JS 里写styles.buttonPrimary） - SSR 场景下用
onlyLocals: true，避免客户端打包注入冗余 locals 对象
哈希稳定但 CSS 文件仍重复加载
看起来类名对了，但浏览器 Network 面板里看到多个同名 main.css 请求，内容一模一样——问题不在 css-loader，而在 mini-css-extract-plugin 的输出配置。
核心是让插件能识别“内容相同就复用”，而不是靠文件名硬匹配：
-
chunkFilename必须带contenthash：'[name].[contenthash:8].css'，不能是'[name].css' - 别在
splitChunks.cacheGroups里给 CSS 单独设name，它会覆盖chunkFilename的 hash 行为 - 如果用了
runtimeChunk: 'single'，确保 CSS 提取不和 runtime 混进同一个 chunk，否则 HMR 会连带刷新样式
哈希规则本身不难配，难的是每处都得对齐：开发/生产环境策略不同、BEM 语义要保全、全局类要主动豁免、插件输出要靠 contenthash 去重——漏掉任何一环，都会让“优化”变成隐形包袱。
