Block名必须业务语义化,因通用词如box、container无法保证项目内唯一性,导致样式污染;正确做法是用product-card、search-form等带明确业务上下文的名称,使单类名即可表达完整归属与语义,不依赖父选择器或外部上下文。

“唯一性”不是指名字起得生僻,而是让每个 block 名在项目中天然不可重名——它直接决定样式是否能真正隔离。
为什么 block 名必须业务语义化,不能用通用词?
类名如 box、container、item 看似简洁,但会在多个组件里重复出现,导致 .box__title 在不同上下文里被同一份 CSS 匹配到,样式互相污染。
正确做法是绑定具体功能:
-
product-card✅(商品卡片) -
search-form✅(搜索表单) -
user-avatar✅(用户头像) -
box❌(无业务指向,无法保证唯一)
只要 block 名来自真实业务模块,且目录结构与命名一致(如 /components/product-card/ → product-card),就能天然避免冲突。
立即学习“前端免费学习笔记(深入)”;
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
为什么不能靠父选择器强化“唯一性”?
写 .product-list .product-card__title 这类路径选择器,看似更安全,实则破坏 BEM 封装性:
- HTML 结构一变(比如加个
<section></section>层),样式就失效 - 组件挪到新页面时,必须连同父容器一起搬,否则样式不生效
- 编译后 CSS 被其他项目引用时,
.product-card__title仍有效,但.product-list可能不存在,整条规则失效
BEM 的唯一性只依赖单类名:.product-card__title 必须自己能表达完整语义和归属,不依赖任何外部上下文。
修饰符(--modifier)的唯一性陷阱在哪?
修饰符本身不自带作用域,必须依附于明确的 block 或 element:
-
.nav-item--active✅(属于 nav-item 这个 element) -
.is-active❌(全局状态类,无法锁定归属,易冲突) -
.product-card--large✅(块级变体) -
.product-card__image--rounded✅(元素级变体) -
.product-card__image--left❌(位置类,响应式下失效,且语义模糊)
所有 -- 开头的修饰符,都必须回答一个问题:“它修饰的是哪个 block 或 element?”答不上来,就是违反唯一性原则。
真正难的不是写对第一个 __ 或 --,而是每次新增组件时,能否坚持用业务实体命名 block,并拒绝“临时起个短名”的诱惑——这是唯一性落地的临界点,也是多数团队半途放弃 BEM 的地方。

















