深层嵌套CSS拖慢渲染，因浏览器从右往左匹配需逐层回溯验证父级；BEM通过扁平单类名（如.form__input）规避此问题，禁用空格选择器、修饰符独立、子元素用新块名，配合工具检查确保无嵌套。
为什么深层嵌套CSS会拖慢渲染
浏览器解析CSS时，会从右往左匹配选择器。比如 .header .nav .item a:hover，引擎得先找所有 a:hover，再逐层向上验证父级是否匹配。嵌套越深，回溯越多，尤其在DOM变动频繁时（如悬停、动画），重排重绘成本明显上升。
BEM本身不提速，但强制扁平命名（.menu__item--active）天然规避了多层嵌套，让选择器变成单类名匹配——这是最快速的匹配方式。
常见错误现象：
- 写成
.sidebar .list .item .link却以为“结构清晰” - 用预处理器嵌套生成深层选择器，比如 Sass 里
.card { .header { .title { ... } } }
BEM命名必须避开的三类嵌套陷阱 BEM不是加三个下划线就完事，关键在“不依赖层级关系”。很多团队名义用BEM，实际仍靠嵌套保底，等于白干。
实操建议：
- 禁止在CSS中出现空格分隔的选择器，如
.block .element—— 全部改用.block__element - 修饰符不继承父级状态，
.button--primary要能独立生效，不能依赖.button的存在 - 组件内子元素若需样式隔离，用新块名而非嵌套，比如弹窗里的按钮写
.modal__close-button，而不是.modal .button
如何检查现有CSS是否真符合BEM性能逻辑 光看文件名或注释没用，得看最终生成的选择器字符串。
使用场景：
- 构建后打开 DevTools → Elements → 选中元素 → 查看 Computed 面板右侧的 “Styles” 标签页，点开对应规则，确认选择器是单类名（如
.form__input）而非带空格的组合（如.form .input） - 用
grep -r "\.[a-z]\+ \.[a-z]" src/css/快速扫出含空格的选择器（Linux/macOS） - Webpack 用户可在
css-loader配置中启用exportOnlyLocals: true，避免意外注入全局嵌套规则
伪类和响应式怎么写才不破功
很多人一加 :hover 或 @media 就退化回嵌套写法，比如 .card:hover .card__title，这又引入了运行时层级判断。
参数差异与性能影响：
立即学习“前端免费学习笔记（深入）”；
-
.card__title:hover是合法且高效的，但语义错——标题自己没法 hover，应写.card--hovered .card__title，由JS切换修饰符 - 媒体查询内必须保持BEM扁平性：
@media (min-width: 768px) { .header__logo--large { ... } }，而不是@media (...) { .header .logo { ... } } - 慎用
:is()或:where()包裹BEM类，它们虽简化书写，但部分旧浏览器不支持，且可能掩盖真实选择器复杂度
.parent .child，浏览器就得为它多做一次祖先遍历——这个细节，上线前很容易被忽略。 
