BEM类名越写越长是因为依赖人工维护命名唯一性与层级语义，易因嵌套深、状态多导致如.product-card__image-wrapper--hover-disabled式冗长命名；CSS Modules则通过构建时自动生成哈希类名（如Button_active_abc123）实现天然隔离，无需手动拼接，避免重名与维护失控。
为什么BEM类名越写越长，而CSS Modules从不担心重名
BEM靠人脑维护命名唯一性，CSS Modules靠构建工具生成哈希类名。前者是“约定大于配置”，后者是“编译即隔离”。
常见错误现象：.header__nav__item--active 这种三层嵌套在BEM里已属反模式，但实际项目中常出现 .product-card__image-wrapper--hover-disabled 类似的超长名——它不是错，而是人力边界被反复试探的结果。
- BEM的
block__element--modifier结构必须手动拼接，状态变化（如isLoading）需在JS里用字符串模板或条件判断生成类名，易漏、易错、难调试 - CSS Modules中
styles.active永远指向一个编译后唯一的哈希类（如Button_active_abc123），哪怕另一个组件也定义了.active，也不会冲突 - 性能影响：BEM无运行时开销；CSS Modules在构建阶段多一次哈希计算，但对现代打包工具几乎无感
webpack中启用CSS Modules时，modules和localIdentName怎么配才不踩坑
直接开modules: true可能让老项目崩溃——因为所有.css文件都会被模块化，而你可能只希望.module.css走这套逻辑。
正确做法是按文件后缀区分：
立即学习“前端免费学习笔记（深入）”；
- 匹配
/\.module\.css$/而非/\.css$/，避免全局CSS（如重置样式、字体引入）被意外模块化 -
localIdentName别用默认值；推荐[name]__[local]--[hash:base64:5]，既保留可读性（Button__primary--abc123），又确保哈希足够短且唯一 - 如果项目用TypeScript，务必配合
declare module '*.module.css'声明，否则import styles from './Button.module.css'会报类型错误
Vue里<style scoped>和<style module>本质区别在哪
<style scoped>是属性选择器模拟局部作用域，<style module>是真正的CSS模块导入——二者解决的是同一问题，但路径完全不同。
典型误用场景：在Vue单文件组件里同时写<style scoped>和<style module>，结果发现$style对象为空，或者scoped样式没生效。
-
<style scoped>给元素加data-v-xxx属性，CSS规则变成.example[data-v-f3f3eg9]，依赖属性匹配，对CSS选择器层级敏感（比如.parent .child可能因属性不在同一节点失效） -
<style module>把类名转成哈希并注入$style对象，你必须显式用:class="$style.red"绑定，不存在“自动作用于template内所有.red”的逻辑 - 兼容性：scoped在Vue 2/3都稳定；module需vue-loader支持，且Vue 3中
<style module>默认导出为defineComponent的styles选项，写法略有差异
BEM还能用吗？什么情况下必须切到CSS Modules
能用，但前提是团队能持续约束命名、项目没有高频状态切换组件、也不需要跨框架复用样式逻辑。
一旦出现以下任一情况，BEM的维护成本会指数级上升：
- React/Vue组件中频繁通过
className={`${base} ${isActive ? active : ''}`}拼接类名——这已经是在用JS模拟CSS Modules该干的事 - 设计系统要支持主题切换，需动态替换
var(--color-primary)，BEM无法提供变量注入能力，而CSS Modules配合:export或CSS自定义属性可解 - 需要做样式单元测试（比如断言某个按钮是否渲染了
primary类），BEM只能测字符串，CSS Modules可直接测styles.primary是否存在
真正容易被忽略的点是：BEM的“块”概念天然绑定HTML结构，而CSS Modules的“模块”绑定的是JS模块——当一个组件拆成多个子组件、或需要逻辑复用（如表单验证样式）时，后者能自然沿用import/export机制，前者只能靠文档或约定硬记。
