BEM类名能直接表达组件结构关系，因其block__element--modifier三段式强制映射真实组件层级：如.dialog对应Dialog.vue，.dialog__header即其直属子结构，不可脱离.dialog单独存在，且__仅限块与直接子元素间，不反映HTML嵌套深度。
因为BEM把“样式归谁管”这个问题，用类名本身说清楚了——不是靠工具隔离，也不是靠人记规矩，而是让每个class都自带上下文和边界。
为什么BEM类名能直接表达组件结构关系
BEM的block__element--modifier不是随意拼接，而是强制映射到真实组件层级：一个.dialog块对应Dialog.vue文件，.dialog__header就是它内部的子结构，不能脱离.dialog单独存在。这种命名让开发者看类名就能反推DOM结构和组件职责。
常见错误现象：.card__header__title看似合理，实则破坏BEM规则——__header__title意味着三层嵌套，但BEM只允许块→元素两级；正确写法是.card__title（如果标题是卡片一级元素）或另起一个.header__title块。
-
__只用于块与**直接子元素**之间，不反映HTML嵌套深度 - 元素名必须语义化，如
__icon、__content，而非__div、__wrapper - 同一块内不允许两个元素名重复，哪怕在不同子组件里（如
.button__icon和.input__icon必须分属不同块）
修饰符--为什么必须绑定到具体块或元素
修饰符不是全局开关，而是局部状态声明。.button--disabled和.button__icon--hidden是两套独立逻辑，前者影响整个按钮行为，后者只控制图标可见性。一旦写成.disabled或.is-hidden，就失去归属，JS反复增删还会触发重排。
立即学习“前端免费学习笔记（深入）”；
使用场景中容易混淆的点：
-
--loading描述状态变化（按钮正在加载），优于--is-loading（条件判断，语义弱且易被滥用） -
--mobile这类响应式修饰符应作用于Block（如.product-list--mobile），表示整体布局切换；若只调元素位置，用.button__icon--right - 多个修饰符可共存：
.input--error--focused合法，但.input.is-error.is-focused会因CSS权重和JS控制路径发散而难收敛
为什么纯BEM仍需配合构建工具才能防冲突
BEM命名本身不解决类名全局污染问题。即使你写了.ui-button__icon--large，另一个包里照样可以定义同名类并覆盖样式。它只是让冲突变得**可识别、可定位、可规避**。
真正起隔离作用的是构建阶段的处理：
- CSS Modules对
ui-button__icon做哈希后变成ui-button__icon_Mx9k2，但前提是类名本身符合BEM结构，否则哈希后语义全失 - Vite +
style:scoped依赖BEM类名不跨块嵌套，否则& .header这种写法会意外穿透作用域 - CI检查必须校验：组件目录名
ui-button→ CSS中只允许出现.ui-button*开头的类，禁止.form-button__field混入
手写__和--为什么是高危操作
人工拼接类名错误率极高：漏下划线（.button_element）、错用短横（.button-element）、大小写不一致（.Button__icon），都会导致样式失效且难以调试。
实操建议：
- Vue项目用
useNamespace封装：ns.e('icon').m('loading')生成ui-button__icon--loading - React项目引入
bem-cn或自建createBEM工厂函数，禁止模板中硬编码class="xxx" - 所有
__/--必须由工具生成，连测试快照里的类名也应走同一函数，避免“开发写对、测试写错”
最常被忽略的不是语法细节，而是BEM要求你为每个视觉单元主动回答三个问题：“它是不是独立块？”“它是不是某块的固有部分？”“它的变体是否需要被其他模块感知？”——这个思考过程本身，比双下划线更重要。
