bem通过扁平化类名减少css重排重绘。其右向匹配高效、规避高成本选择器、支持引擎缓存；须严格遵循三段式语义分层，避免状态混入；与css-in-js或tailwind共存时需分层协作；构建工具配置错误和语义模糊才是真性能瓶颈。
为什么BEM能减少CSS重排重绘
浏览器解析CSS选择器是从右往左匹配的。.header__title--large这种BEM类名，末尾是具体元素，匹配路径短；而.container .header .title这种嵌套写法，浏览器得先找所有.title，再逐个向上验证父级，开销大得多。
- 深层嵌套选择器（如
div ul li a:hover）在DOM变化时触发更频繁的样式计算 - BEM强制扁平化命名，天然规避
:not()、属性选择器、伪类连用等高成本组合 - 现代CSS引擎对单类名（
.btn--primary）有缓存优化，重复类名复用率高
BEM类名不是加长就安全：三段式结构必须严格分层
BEM要求block__element--modifier中三部分语义隔离。常见错误是把状态和结构混在一起，比如写成.card__content--hover——hover是交互状态，不该进类名；应该用.card__content.is-hovered或JS切换.card__content:hover。
-
block对应可复用的独立组件（.modal、.tooltip） -
__element必须是block的直属子节点，不能跨层（禁止.modal__footer__button） -
--modifier只表达外观/行为变体，不改变结构（.btn--disabled合法，.btn--with-icon不推荐，应拆成.btn__icon）
如何避免BEM与CSS-in-JS或Tailwind的冲突
纯BEM在React/Vue里容易和CSS Modules或styled-components的局部作用域打架；直接混用Tailwind又会让class="btn btn--primary bg-blue-500"失去BEM语义一致性。
- 用CSS Modules时，把BEM类名作为
className值传入，不依赖全局命名（styles['btn--primary']） - 和Tailwind共存时，只用BEM定义结构和块级关系，视觉样式交给Tailwind（
class="card card--featured p-6 bg-white"） - 禁用
@apply封装BEM modifier，会丢失可维护性（@apply btn--primary不如直接写类名）
构建工具链里最容易被忽略的BEM陷阱
PostCSS插件如postcss-bem或Webpack的css-loader配置不当，会导致&__element编译错位，生成无效选择器。
- 检查
css-loader是否启用了modules: { auto: true }，否则localIdentName可能截断BEM下划线 - 用Sass时，
@at-root要慎用，&__item { @at-root .list & { ... } }会破坏BEM层级 - VS Code插件如
BEM Helper自动生成类名时，注意它默认不校验__和--是否紧贴单词，.menu__ item这种空格错误不会报错但无效
真正卡住性能的往往不是BEM本身，而是类名语义模糊导致后续开发者不断加!important或用[style]内联覆盖——这时候再好的选择器规则也救不了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
