bem靠命名约定提升可维护性但无法避免类名冲突，css modules通过构建时哈希化实现样式隔离却牺牲语义可读性；二者结合（如在.module.css中使用bem命名并由css modules编译）可兼顾结构清晰与作用域安全。
直接说结论：BEM 是靠命名约束可维护性，CSS Modules 是靠构建时重命名实现隔离——两者不互斥，但解决的问题层级不同；单独用 BEM 无法避免类名冲突，单独用 CSS Modules 容易让样式失去语义和上下文。
BEM 命名为什么不能防止样式覆盖
BEM 只是一套书写约定，不改变 CSS 的全局作用域本质。即使你严格写 .user-card__title--large，另一个模块里也完全可能定义同名类，最终在 DOM 中发生覆盖。
- 团队协作中，不同人写的
.button--primary可能指向完全不同视觉效果 - 没有构建工具介入，
npm install进来的第三方组件类名也可能撞车（比如两个 UI 库都用了.modal__overlay） - 浏览器开发者工具里看到的仍是原始类名，调试时无法区分“这是哪个文件定义的”
CSS Modules 的类名哈希化带来什么代价
启用 css-loader 的 modules 选项后，.primary-button 会被编译成类似 Button_primaryButton__abc123 的唯一字符串，彻底隔离作用域——但这也切断了命名与结构的直观联系。
- HTML 中 class 属性变成一长串哈希，无法靠眼识别组件归属（
class="Button_primaryButton__x7f9a"） - 服务端渲染或调试时，原始类名丢失，排查样式来源需反复跳转到对应
.module.css文件 - 若用
localIdentName: '[name]__[local]--[hash:base64:5]'，类名虽保留语义，但哈希部分仍不可读，且构建产物体积略增
真正提升可维护性的组合用法
把 BEM 的语义结构 + CSS Modules 的作用域保障结合起来，才是兼顾可读性与安全性的常见实践。
- 在
Button.module.css里继续用 BEM 风格命名：.button、.button__icon、.button--loading - 导入后通过对象解构使用：
import styles from './Button.module.css';→className={styles['button--loading']} - 这样既保留在源码中可读的结构关系，又确保运行时不会被外部样式干扰
- 注意：BEM 修饰符中的双连字符
--在 JS 对象属性中需加引号，否则语法报错
最常被忽略的一点：BEM 的 __ 和 -- 是人为约定，而 CSS Modules 的哈希是机器生成——前者靠人守规矩，后者靠工具兜底。项目越早统一这两层规则，后期改版时动一个按钮样式却意外影响导航栏的概率就越低。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
