浏览器匹配选择器时从右往左验证，如.page .main .content .card .title先找所有.title再逐级向上检查父级，DOM节点多时性能骤降；BEM和@at-root可切断匹配路径、减少回溯。
浏览器匹配选择器时真正在做什么
写 .page .main .content .card .title 这种 5 层选择器，浏览器不是从左往右“钻 DOM”，而是从右往左：先找所有 .title 元素，再对每个逐个向上验证父级是否为 .card、再查 .card 的父级是不是 .content……每多一层，就多一次 DOM 树向上遍历。DOM 节点一多（比如商品列表里有 200 个 .title），CPU 就猛涨。
这不是 SCSS 编译慢，是运行时真卡。低端 Android 设备上，4 层已开始掉帧；5 层在虚拟滚动区域常触发 Recalculate Style 飙升、hover 卡顿。
-
.a .b .c .d的 specificity 是0,0,4,0，而单类名.d只有0,0,1,0—— JS 动态加is-active很难覆盖，常逼你加!important - DevTools “Computed” 面板里生效样式被压在十几条灰色规则下，人工定位要反复验证父级路径是否成立
- VS Code 的 CSS Peek 对深层嵌套支持弱，点击跳转常停在错误层级
@at-root 不是缩进逃逸键，是语义提级开关
@at-root 解决的不是“我不想缩进”，而是“这段样式逻辑上不属于当前嵌套路径”。硬撑嵌套会产出 .modal .header .u-text-center 这种冗余选择器，但你真正只需要 .u-text-center。
-
@at-root .u-text-center { text-align: center; }→ 输出.u-text-center，无前缀，零回溯 -
@at-root (with: .theme-dark) { .button { color: white; } }→ 输出.theme-dark .button，只加必要上下文 - 别在
@media块里滥用&嵌套：@media (min-width: 768px) { .card { &__body { } } }，若外层还有.layout .dashboard，& 会展开全部路径，生成@media (min-width: 768px) { .layout .dashboard .card__body { } }（6 层起步）
BEM 不是命名习惯，是匹配路径切断协议
BEM 的核心作用，是让每个样式只依赖一个类名，彻底绕过浏览器向上查找父级的过程。它不是语法糖，是语义映射：card__title 必须显式出现在 HTML 中：<h2 class="card__title">。缺 card 就完全不匹配，但也因此不再怕 DOM 结构变动。
立即学习“前端免费学习笔记（深入）”；
- 禁止
card__header__logo这种跨层 Element，应拆为card__header和card__logo - 修饰符用
--：.button--primary，不是.button-primary，避免与组件名冲突 - 父子关系靠类名表达，而非嵌套结构：
.header .nav-link替代.header { .nav { .link { } } } - 标签名嵌套（如
ul li a）最危险：HTML 改成ol或加了 wrapper，样式全挂
%placeholder + @extend 的三条铁律
@extend 不是复用样式，是编译期机械拼接选择器。滥用会让 CSS 体积爆炸，尤其多个组件共用同一基础类时。真正安全的路径是 %placeholder + 严格边界 + @mixin 补位。
- 必须以
%开头声明，例如%text-emphasis；写成.text-emphasis或text-emphasis都无效 - 必须被至少一个
@extend调用，否则编译后彻底消失——你查不到它，也 debug 不到它 - 不能出现在嵌套规则内部：
.card { .title { @extend %heading; } }是危险操作，Sass 会尝试拼接.card .title和%heading的全部上下文路径，产出类似.card .card .title的冗余选择器
真正影响性能的不是“写了什么”，而是“改了什么”。高频更新区域（如滚动列表项、动画容器）只要用了含空格的选择器（哪怕只有两层，如 .item .title），每次 layout 触发都要重跑整条匹配链。重构时，别只盯着删缩进，重点是把“依赖结构推导”换成“靠类名显式表达”。
