单类名选择器比嵌套选择器快，因浏览器从右往左匹配，.header__logo--dark可直接哈希查找；而.header .header__logo--dark需先找所有目标元素再逐层回溯父节点，DOM越深开销越大，低端设备上慢4倍以上。
因为浏览器匹配 CSS 选择器时从右往左，.header__logo--dark 这种单类名能直接哈希查找；而 .header .header__logo--dark 会强制逐层向上回溯父节点，DOM 越深、元素越多，开销越明显——尤其在低端 Android 设备上，一次匹配可能慢 4 倍以上。
为什么单类名选择器比嵌套选择器快得多
浏览器不解析类名语义，只做字符串匹配和 DOM 树遍历。关键选择器（最右边那个）决定初始查找范围：.card__title 直接定位所有含该 class 的元素；.card .card__title 则先找全部 .card__title，再挨个检查其父级是否含 .card。
- DOM 深度每增加一层，回溯成本非线性上升；5 层嵌套在 Redmi Note 8 上实测单次匹配耗时达 0.5–2ms
- 滚动或悬停触发频繁样式重计算时，这种开销会集中爆发，直接导致帧率跌破 60fps
- 空格不是“看起来多写了一个字符”，而是引入了后代组合器，彻底改变匹配路径
哪些 BEM 写法看似合规，实际破坏性能优势
名字带双下划线 ≠ 真 BEM。很多团队用 Sass 写了 .card { &__title { } } 就以为安全，结果一加 &:hover 或误用 @at-root，就编译出带空格的选择器。
-
.card { &__content { &:hover { } } }→ 编译为.card .card__content:hover，空格回来了 -
.modal__content在 HTML 里被包裹在<div class="modal"><div class="modal__content">中，但 CSS 仍写.modal .modal__content，完全违背 BEM 扁平原则 -
.button__icon:hover表面看是单类名，但语义错（图标自己不响应 hover），正确做法是.button--hovered .button__icon或.button__icon.is-hovered
如何验证你的 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这类写法
真正难的不是拼对 __ 和 --，而是每次写类名前都得问：这个元素是不是它所属 Block 的固有部分？这个修饰符是不是可枚举、可复用、不带硬编码值的状态？这种判断没法靠工具兜底，只能靠人盯住。
