BEM通过将语义与作用域固化在单个类名中，避免后代选择器等运行时计算，提升CSS匹配效率；需规范生成类名、规避冗余场景，并用工具校验合规性。
为什么BEM命名能减少CSS选择器匹配开销
浏览器解析CSS时，是从右往左匹配选择器的。比如 .header__title--large 这种BEM类名，末尾的 --large 是唯一性高、结构固定的后缀，浏览器能快速定位到目标元素；而 header .title.large 这类依赖层级和多类组合的选择器，需要反复回溯父节点、检查多个类是否存在，匹配路径更长。
关键不是“名字变长了”，而是BEM强制把语义和作用域固化在单个类名里，避免了后代选择器、属性选择器、伪类嵌套带来的运行时计算膨胀。
如何正确生成BEM类名而不破坏可维护性
手动拼接容易出错，也难统一。推荐用预处理器函数或构建时工具自动生成，而不是靠人脑记忆规则。
-
block名必须是独立模块的根容器，比如card、form-field，不能是user-card（含业务语义）或big-card（含样式语义） -
element必须直属于block，写成card__header__logo是错的，应为card__logo（logo属于card，不属header） -
modifier只能修饰block或element，且必须带连字符前缀，如card--disabled、card__button--primary；card__button-primary会和card__button-primary-icon产生歧义
哪些场景下BEM反而拖慢渲染或增加冗余
BEM不是银弹。当模块复用率极低、DOM结构简单、或需要高频动态切换状态时，硬套BEM可能适得其反。
- 单页内只出现一次的弹窗，用
modal--confirm+modal__content不如直接用confirm-modal+confirm-modal-content更轻量 - 动画类名频繁增删（如
is-open、is-animating），BEM要求写成modal--is-open，但这类状态类本质是JS控制的开关，没必要绑定模块前缀 - CSS-in-JS方案（如Emotion、Styled Components）已通过哈希隔离作用域，再套BEM类名只是徒增字符串长度，对查找效率无实质提升
构建阶段能否自动校验BEM命名合规性
可以，而且强烈建议加。ESLint配合 stylelint-selector-bem-pattern 插件能捕获90%的常见错误，比如：
❌ 错误： .card-header-title（缺少双下划线，被识别为嵌套后代）
✅ 正确： .card__header__title 或更合理的 .card__title
注意：正则规则要根据团队约定微调，比如是否允许数字开头、是否禁用 js- 前缀类。默认配置不识别 card__title--sm 中的 --sm，需显式开启 componentName 模式。
真正难检测的是语义越界——比如把一个按钮单独抽成 button-group__item，实际它根本不属于 button-group 的DOM子树。这种只能靠Code Review卡住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
