盒模型嵌套过深本身不慢，真正拖垮渲染的是选择器写法——浏览器从右往左匹配，每多一层空格分隔的父级，就要对每个候选元素做一次向上遍历验证；4层就是临界点，不是建议值，是实测卡顿起点。
盒模型嵌套过深本身不慢，真正拖垮渲染的是选择器写法——浏览器从右往左匹配，每多一层空格分隔的父级，就要对每个候选元素做一次向上遍历验证。4层就是临界点，不是建议值，是实测卡顿起点。
为什么删 div 不能解决性能问题
很多人一看到嵌套深就去“扁平化DOM”，把 <div class="card"><div class="header"><h2>标题</h2></div></div> 改成 <div class="card__header"><h2 class="card__title">标题</h2></div>，但若CSS仍写 .card .header .title，照样回溯三层。DOM层级和选择器层级是两回事，后者才是瓶颈根源。
- DOM只有一层，但选择器写成
section > article div p em，依然触发深度回溯 - JS调用
element.classList.add("is-active")失效，常因现有规则权重太高（比如.page .main .nav .item.active），被迫加!important - DevTools里“Computed”面板显示生效样式被压在几十条被覆盖的规则下面，调试时间翻倍
BEM不是命名规范，是匹配路径切断协议
BEM的核心作用，是让每个样式只依赖一个类名，彻底绕过浏览器向上查找父级的过程。它不是语法糖，是语义映射：把“这个标题属于卡片”编译成 card__title 这个原子类名，而非靠结构推导。
-
card__title必须显式出现在HTML中：<h2 class="card__title">，缺card就完全不匹配 - 禁止
card__header__logo这种跨层Element，应拆为card__header和card__logo两个独立元素 - 修饰符必须能独立生效：
button--loading不该依赖button类存在，否则JS切换失败 - 禁用标签名参与组合：
ul.nav li a是高危写法，HTML结构微调即全挂
@at-root 不是逃逸键，是语义提级开关
SCSS的 & 嵌套容易让人误以为缩进=作用域隔离，其实编译后仍是普通CSS。当某段样式逻辑上属于组件、但不该继承当前路径时，硬撑嵌套只会产出冗余选择器。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
.theme-dark { .menu { &__item:hover { } } }→ 编译出.theme-dark .menu .menu__item:hover（4层） - 正确提级：
.theme-dark { @at-root .menu__item.theme-dark:hover { } }→ 输出.menu__item.theme-dark:hover（单类+修饰符） - 媒体查询内禁用
&嵌套：@media (min-width: 768px) { .card { &__body { } } }看似干净，但外层若有嵌套，&会展开全部路径 - 工具类必须提级：
@at-root .u-text-center { text-align: center; }，否则可能编译成.modal .u-text-center
移动端和构建链路里的隐形炸弹
这些地方不报错，但一上线就卡：esbuild处理10层SCSS嵌套时，可能生成10万种选择器组合，直接内存溢出；Android旧版WebView根本不认原生CSS嵌套语法，整条规则静默失效。
- 高频更新区域（如滚动列表项）禁用任何空格选择器，哪怕只有两层：
.list .item比.list-item慢3倍以上 - 用
grep -r "\.[a-z]\+ \.[a-z]" src/css/扫描项目，快速揪出残留的空格选择器 - Chrome DevTools → Rendering 面板勾选 “Layout Shift Regions”，红色闪烁区域就是深层选择器正在拖慢重排
- 构建时开启
exportOnlyLocals: true（css-loader），避免意外注入全局嵌套规则
最常被忽略的一点：性能瓶颈往往不出现在“写了什么”，而出现在“改了什么”。一次看似无害的 classList.toggle 或媒体查询切换，可能触发整条选择器链重匹配——这时候你才意识到，那个写着 .a .b .c .d 的规则，早就埋在CSS文件第300行了。
