BEM规范本身不减少重绘和重排，因其不参与layout和paint阶段；它仅影响CSS选择器匹配效率，真正性能提升来自配套的布局优化（如改flex为grid）而非命名本身。
BEM规范本身完全不减少重绘（repaint）和重排（reflow）——它压根不参与 layout 和 paint 阶段的计算。
浏览器在执行重排时，只关心你改了哪些 CSS 属性（比如 width、display、margin、top），根本不解析类名里有没有双下划线或两个短横。.card__item 和 .item 触发重排的条件一模一样，只要它们最终应用的样式规则中包含 layout 变更。
所以如果你看到“用了 BEM 后列表滚动变卡”或“hover 一下整个页面抖动”，问题一定不在类名写法，而在：
-
height未设固定值，导致 flex/grid 容器反复测量内容高度 -
:hover里改了margin或padding，触发父容器尺寸变化 -
display: none↔block切换，强制整块子树重排 - JS 频繁读取
offsetHeight或getComputedStyle，引发强制同步布局
BEM 真正影响的是选择器匹配阶段（CSSOM 构建）
这个阶段发生在 style 计算前，不涉及像素绘制，但对首屏渲染和动态 class 切换有实际影响：
立即学习“前端免费学习笔记（深入）”；
- ✅ 单类名如
.header__logo--dark：浏览器直接哈希查表，O(1) 时间 - ❌ 组合选择器如
.page-home .header .header__logo--dark：必须从右往左逐层向上找父节点，DOM 深时开销明显上升 - ⚠️ 特别注意
.card:hover .card__title：每次 hover 状态变化都要重新遍历父级关系，应改为.card--hovered .card__title并由 JS 控制修饰符切换
为什么很多人误以为 BEM 能“优化重排”
常见错觉来源：
- 团队把
.list .item改成.list__item后，顺手删掉了原来写在.list上的display: flex→ 实际是 layout 规则减少了，不是类名功劳 - 重构时顺便把
float: left换成display: grid→ 性能提升来自布局模型升级，和 BEM 无关 - 旧项目里大量
body .main .content p这类选择器，BEM 强制扁平后，CSS 规则数下降、tree-shaking 更有效 → 减少了样式计算量，但仍是 style 计算，非 layout
检查你是否真受益于 BEM 的性能逻辑
别信文件名或注释，看 DevTools 实际生效的选择器：
- 打开 Elements 面板，选中一个元素
- 切到右侧 Styles 标签页，展开某条规则
- 确认选择器字符串是纯单类名（如
.form__input），而不是带空格/符号的组合（如.form .input或.form > .input） - 如果发现
.modal .modal__close，说明 BEM 约束已被绕过，匹配开销已回升
真正容易被忽略的点：BEM 的价值不在运行时性能数字，而在于它用命名约束，倒逼你放弃易引发重排的写法（比如靠父级 display 控制子元素布局），并让样式归属清晰到可预测——这使得你在加 will-change: transform 或做动画优化时，能准确定位该加在哪一层，而不是靠猜。
