后代选择器性能问题源于浏览器从最右选择器向上回溯验证，嵌套过深导致recalculate style时间飙升；应限制层级≤3、用bem替代深度嵌套、慎用&、优先使用子代选择器>或data属性。
后代选择器本身不是问题，嵌套过深才是
浏览器匹配 .a .b .c .d 时，不是从 .a 往下找，而是先抓所有 .d 元素，再逐层向上验证父级是否为 .c、.b、.a。DOM 节点越多，回溯越重，Recalculate Style 时间飙升是直接表现。
常见错误现象：.page .main .content .card .title 这类 5 层写法，在低端 Android 设备上比 .card__title 慢 4 倍以上；DevTools 里“已计算样式”面板中真正生效的规则被压在十几条失效规则底下；改一个中间类名（如 .main → .layout），整条规则静默失效，连报错都没有。
- 限制实际使用的后代层级 ≤ 3 层（
.block .element .modifier是临界值，再深就该重构） - 禁用纯标签选择器组合，如
div ul li a—— 它强制全量扫描，权重低但性能更差 - 避免用
:not(.valid) input[type="text"]这类组合，会让浏览器放弃哈希索引，退化为字符串比对
用 BEM 类名替代后代路径，不是加长名字而是收口语义
.card__title 不是“为了命名而命名”，它是把 DOM 层级关系翻译成类名结构：浏览器一次匹配 .card__title 就结束，不用回溯；开发者一眼知道它属于 card 组件，且是其直属 title 元素。
真实使用场景：后台权限菜单、多级弹窗、动态表单字段组 —— 这些结构常超 4 层 DOM 深度，但样式不该跟着 DOM 深度走。
- Block 名必须是功能单元，如
search-form✅，拒绝top-nav❌（含位置）、card❌（泛称） - Element 只能是 Block 的直属子节点，
product-card__header__logo❌ 违反原则，应拆为product-card__logo或新建 Block - Modifier 只表达状态，
search-form--compact✅，禁止search-form__input--disabled❌（那是 input 自己的 Modifier）
Sass/Less 中 & 的误用会悄悄加重嵌套
& 不是“当前缩进上下文”，而是“父选择器字符串拼接结果”。很多人写 .btn { .icon { &--small { } } }，以为生成的是 .btn .icon--small，实际是 .icon--small —— 因为 & 此时指代的是 .icon，不是外层 .btn。
这种误用导致样式意外失效、调试困难，尤其在组件复用时。
- 检查
&前有没有空格：有空格是后代选择器，没空格才是拼接 - 想保留外层上下文？用变量暂存：
$block: ".card"; #{$block}__title { } -
@at-root不是用来“救”深层嵌套的，它只适合媒体查询提级或脱离父级上下文，比如@at-root @media (min-width: 768px) { &--large { } }
真要依赖结构时，优先用子代选择器 > 或 data 属性
当必须按 DOM 位置区分样式（比如 WordPress 菜单、<ol></ol> 编号嵌套），> 比空格更可控：它切断了“意外继承”，也避免编译出过长的选择器链。
移动端或异步渲染场景下，data-depth 更可靠 —— DOM 结构一动，.comment .comment .comment 就崩，但 [data-depth="3"] 始终有效，匹配快、不回溯、JS 设置简单。
- 菜单层级控制：
#primary-menu > .sub-menu（一级）、#primary-menu > .sub-menu > .sub-menu（二级） - 列表编号分层：
ol { list-style: upper-roman; } ol > ol { list-style: lower-alpha; } ol > ol > ol { list-style: decimal; } - 动态插入元素时，直接设
el.dataset.depth = 4，CSS 写[data-depth="4"] { margin-left: 80px; }
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
