BEM与reflow无直接关系，因其仅为命名约定，浏览器layout阶段不解析类名语义；是否触发重排取决于样式声明中的几何属性变更，而非类名结构。
使用 BEM 不能降低 CSS 引起的「回流（reflow）」成本——它根本不管 layout 计算，也不影响浏览器重排逻辑。
为什么 BEM 和 reflow 没有直接关系
BEM 是一套类名命名约定，浏览器在 layout 阶段不解析类名语义，只读取最终计算出的样式声明。是否触发重排，取决于你改的是 width、height、display 这类几何属性，而不是类名里有没有双下划线。
常见错误现象：
- 团队以为 “用了
.card__content就比.content渲染更快” —— 实际上两者匹配开销几乎一致 - 长列表滚动卡顿，归因于“BEM 类名太长”，真实原因是
flex-wrap+ 百分比padding或在:hover里改了margin
BEM 真正影响的是 CSS 选择器匹配性能
浏览器从右往左匹配选择器，关键选择器（最右边那个）决定初始查找范围。BEM 强制单类名写法，避免了深层嵌套带来的回溯开销。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- ✅ 正确：
.header__logo--dark→ 浏览器哈希查一次即可定位元素 - ❌ 错误：
.page-home .layout-main .header .header__logo--dark→ 先找所有.header__logo--dark，再逐层向上验证父级是否存在 - ⚠️ 注意：
.card:hover .card__title看似合理，但运行时需动态验证 hover 状态；应改为.card--hovered .card__title，由 JS 控制修饰符切换
哪些 BEM 写法会间接放大重排风险
BEM 本身不触发重排，但某些退化用法会埋下隐患：
- 禁用
.list .item类选择器，否则改.list的display会导致整列重算 - 禁止在修饰符中混入布局控制：如
.button--full-width实际设置了width: 100%，这会让按钮在不同容器中反复触发 layout - 用
all: unset在 block 范围内清样式，再显式声明width、padding等，比依赖全局 reset 更可控
最容易被忽略的是：BEM 命名再规范，只要规则里写了 float: left 或 position: absolute，照样引发重排。别把性能问题寄托在类名结构上，该查 DevTools 的 Layout 标签页，就别只盯着 class 属性看。
