不破坏。CSS Modules 的哈希仅作用于最终 class 属性值，原始 BEM 类名（如 button__text）完整保留在源码中，作为 key 用于 JS 访问和开发调试，语义由源码承载，隔离由哈希实现。
Webpack中css-loader开启modules后，类名哈希化是否破坏BEM语义
不破坏。CSS Modules 的哈希只作用于最终生成的 class 属性值，原始 BEM 类名（如 button__text、button--large）仍完整保留在源码和开发体验中，且被构建工具用于定位、校验与模块绑定。
关键点在于：css-loader 的 modules: true 不是“重命名”，而是“映射”——它把你在 .module.css 里写的 BEM 类名作为 key，生成带哈希的 value；JS 中通过 styles.button__text 访问，HTML 中渲染的是 button__text_abc123。语义由源码类名承载，隔离由哈希实现。
- 禁用
localsConvention默认值会导致button__text在 JS 中变成buttonText，丢失双下划线结构，搜索和校验全失效 - 若手动设
localIdentName: '[hash:base64]'，调试时无法反查源文件——必须保留[name]__[local]片段，例如[name]__[local]--[hash:5] - Vite 默认启用 CSS Modules 且保留 localsConvention: 'camelCaseOnly'，但 Webpack 需显式配置，否则
card__header--dark在 JS 中会变成cardHeaderDark，破坏 BEM 可读性
压缩阶段如何避免BEM类名被css-minimizer-webpack-plugin误删或混淆
默认情况下，css-minimizer-webpack-plugin 不会删除或改写类名字符串，但它可能压缩选择器层级、合并重复规则，从而让 BEM 的结构意图在压缩后 CSS 中变得模糊——尤其是当多个 Modifier 共享相同声明时。
真正风险来自两点：一是插件启用了 mergeLonghand 或 reduceTransforms 等激进优化；二是你没关掉 CSS source map，导致压缩后 DevTools 里看不到原始类名对应关系。
立即学习“前端免费学习笔记（深入）”；
- 务必在
css-minimizer-webpack-plugin配置中关闭高危选项：mergeLonghand: false、reduceTransforms: false - 确保
devtool: 'source-map'（Webpack）或build.cssCodeSplit: false（Vite）开启，否则header__logo--dark在 Elements 面板里点不到源文件 - 不要依赖压缩后的 CSS 文件去 grep 类名——所有搜索、校验、调试都必须基于未压缩的
.module.css源文件
为什么postcss-bem-linter在校验时总报“element not under block”
因为 postcss-bem-linter 不解析类名前缀，也不推断文件路径，它只认顶部注释指令 /* postcss-bem-linter: define .block-name */。没有这行，哪怕你写了 .user-card__title，它也认为 user-card__title 是孤立 element。
这个错误不是压缩导致的，而是在 PostCSS 处理链早期就发生的静态校验失败。一旦报错，Webpack 构建会中断（除非你配了 throwOnError: false），根本走不到压缩阶段。
- 每个
.module.css文件顶部必须加定义注释，例如：/* postcss-bem-linter: define .search-bar */ - SCSS 嵌套中用
&__input编译后是.search-bar__input，但 linter 运行在 PostCSS 层，看不到&，仍需顶部定义 - Vite 项目容易漏掉：默认
.css不走 PostCSS，需在vite.config.ts显式配置css.postcss.plugins并引入@projectwallace/postcss-bem-linter
生产环境打包后，怎样快速验证BEM类名语义是否还在起作用
不能看最终 HTML 的 class 属性值（它已经是哈希化的），而要看三件事：浏览器 DevTools 中 Styles 面板能否点击类名跳转到源文件、控制台能否用 document.querySelector('[class*="user-profile__avatar"]') 定位元素、全局搜索 user-profile__avatar 能否命中唯一 CSS 文件。
最容易被忽略的是：如果用了 css-loader 的 exportLocalsConvention: 'asIs' 却忘了配 modules.exportGlobals: true，某些动态插入的样式（比如 emotion 注入）可能绕过模块系统，导致 BEM 类名在 HTML 中“出现两次”——一次是哈希化的，一次是原始未哈希的，污染隔离。
- 检查构建产物中的
.css文件，确认里面的选择器仍是.user-profile__avatar而非.userProfileAvatar—— 后者说明 localsConvention 错配 - 运行时执行
Object.keys(styles)，确认返回数组包含'user-profile__avatar'，而不是'userProfileAvatar' - 如果用了
mini-css-extract-plugin提取 CSS，确保它在css-loader之后、style-loader之前，否则模块化逻辑断裂
