CSS BEM命名规范在现代前端项目开发中还适用吗

到了2026年，BEM 命名规范依然没有被真正取代，原因其实很明确：它仅凭一套清晰、稳定的命名规则，就能有效隔离 CSS 样式作用域，完全不必依赖额外的构建工具。反过来看，虽然 CSS Modules 可以通过哈希机制自动处理类名，但一旦导出的类名需要提供给外部使用，命名冲突往往仍然需要人工规避；相比之下，像 BEM 中的 button__icon--loading 这类命名，天然就包含组件归属与状态语义，表达更直观也更完整。

适用，而且在大多数中大型前端项目中，它仍然是首选方案——并不是因为它足够“先进”，而是因为 BEM 解决的是样式冲突、作用域不清、团队协作成本高等这些不会随着技术演进而消失的底层问题。

为什么 BEM 在 2026 年依然没有被替代

BEM 不需要绑定任何构建工具，也无需依赖运行时框架，只靠一套明确的 CSS 命名规范，就能把样式作用域划分得非常清楚。CSS Modules 确实能够自动为类名生成哈希值，但只要类名需要导出给外部组件使用，比如 className={styles.button}，后续依旧离不开人为约束来减少冲突。相比之下，BEM 像 button__icon--loading 这样的写法，即使完全没有构建流程，也能让开发者快速看出它属于哪个模块，以及当前处于什么状态。

• 在微前端场景中，多个团队同时开发时，像 header 这样的通用类名几乎不敢直接使用，只有 app-header__logo--dark 这类写法才能清晰标识归属
• 在 Vue 或 React 组件拆分之后，user-card__a vatar 比 a vatar 更容易通过 grep 搜索定位，同时也能减少 scoped 样式穿透时出现的意外覆盖问题
• 浏览器匹配 .user-card__a vatar--sm 属于单次哈希查找；而 .user-card .a vatar 则需要额外回溯父级节点，DOM 层级一深，性能就更容易下降

哪些情况容易踩坑：伪 BEM 和跨块元素

最常见的问题并不是 BEM 过时，而是很多项目在使用过程中把写法逐渐弱化了。比如：

• ... —— 少了 block 前缀后，.title 一旦进入全局作用域，就很容易发生样式冲突

• 出现在非 search-form 容器中 —— element 脱离所属 block，语义链条被打断，复用时也更容易造成样式错乱

• Sass 中写 .card { &__title { color: red; } & .card-subtitle { ... } } —— 后者最终会编译出带空格的选择器，从而破坏 BEM 原本的命名约束

这类写法表面上看像是在使用 BEM，实际上已经失去了样式作用域的保护能力，真正排查 bug 时往往会更难处理。

Modifier 必须与基础类同时存在，不能单独使用

button--disabled 如果单独使用，会直接丢失所有基础样式，例如 padding、border、font-size 等，因此必须写成 button button--disabled。

• modifier 不是独立的样式单元，它本质上只是对某个 block 或 element 状态的补充描述
• 如果写成 button--width-200px 这类带具体数值的 modifier，后续一旦需要响应式调整宽度，就只能继续新增类名，这违背了“状态可枚举”的原则
• 合法的 modifier 示例： button--primary、button--disabled、button--loading；不推荐的写法： button--bg-blue、button--left

真正困难的地方，不是记住 __ 和 -- 该怎么写，而是每次命名类名时都能克制住“先图省事再说”的冲动——不使用标签选择器、不把具体样式值塞进类名、不跨 block 复用 element 名称。这些约束看起来不起眼，但只要缺少其中任何一条，BEM 就会从一种可靠的工程化规范，退化为一种表面化的命名习惯。