BEM本身不减少重流重绘，只优化CSS选择器匹配性能；其单类名（如.header__logo--dark）支持浏览器从右往左一次哈希查找，而嵌套选择器（如.page-home .header .header__logo--dark）需逐层回溯父节点，显著增加匹配开销。
BEM 本身不减少重流（reflow）和重绘（repaint），它只影响 CSS 选择器匹配阶段的性能；真正触发重流的是 layout 属性变更（如 width、height、display、position），不是类名写法。
为什么 BEM 类名不会让重排变快
BEM 是命名约定，浏览器在 layout 阶段根本不解析类名语义。.card__item 和 .item 的匹配开销几乎一致，只要最终 CSS 规则里没写 width: 100%、float: left 或 display: inline-block 这类易触发重排的声明，滚动或状态切换时就不会多出一次 layout 计算。
常见错误现象：团队以为“用了 BEM 就能优化列表滚动”，结果长列表仍卡顿——问题其实出在未限制 height、用了 flex-wrap + 百分比 padding，或在 :hover 里改了 margin。
- 浏览器不因类名长度或下划线数量做额外计算
- 重排次数取决于样式规则是否引起几何属性变化，而非选择器结构
- BEM 的价值在于间接规避重排陷阱：比如禁止
.list .item，就避免了改.list的display时整列重算
哪些 BEM 写法真会影响选择器匹配性能
浏览器从右往左匹配 CSS，关键选择器（最右边那个）决定初始查找范围。.header__logo--dark 是高效匹配，而 .page-home .layout-main .header .header__logo--dark 就会强制逐层回溯父节点，尤其在移动端 DOM 深、元素多时，开销明显上升。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：直接用
.header__logo--dark，不加任何祖先限定 - ❌ 错误：
.header .header__logo--dark或.header > .header__logo--dark—— 空格和>都引入后代/子代关系，破坏 BEM 扁平性 - ⚠️ 注意：
.card:hover .card__title看似合理，但运行时需验证父级 hover 状态，应改为.card--hovered .card__title，由 JS 切换修饰符
如何检查现有 CSS 是否真符合 BEM 性能逻辑
光看文件名或注释没用，得看最终生成的选择器字符串。构建后打开 DevTools → Elements → 选中元素 → 查看 Computed 面板右侧的 “Styles” 标签页，点开对应规则，确认选择器是单类名（如 .form__input）而非带空格的组合（如 .form .input）。
- Linux/macOS 下可用：
grep -r "\.[a-z]\+ \.[a-z]" src/css/快速扫出含空格的选择器 - Webpack 用户可在
css-loader配置中启用exportOnlyLocals: true，避免意外注入全局嵌套规则 - CI 中建议接入
stylelint-selector-bem-pattern，拦截.modal .modal__close这类退化写法
BEM 在 CSS-in-JS 或 scoped 场景下的真实风险
Vue 的 <style scoped> 或 Emotion 的 css 函数本身会自动加属性选择器（如 [data-v-abc123]），这比单类名匹配更慢。BEM 在这类环境里依然有效，但必须确保编译后不额外引入 [class^="btn"] 或 [data-state="loading"] 这类属性选择器。
- Emotion 若用动态插值：
css`${props => props.theme.primary}`，每次渲染都可能生成新规则，比 BEM 嵌套更难追踪 - Vue scoped 模式下，
.button__icon编译后变成.button__icon[data-v-xxx]，仍属单类匹配，安全；但若手写.button[data-loading]，就引入高成本属性判断 - 真正容易被忽略的是：工具链配置错误（如 PostCSS 插件误启
postcss-attribute-case-insensitive）可能悄悄插入冗余属性选择器
