浏览器匹配.card .header .title极慢，因其从右向左匹配：先查所有.title，再逐个向上验证是否在.header内、是否在.card内，DOM越深回溯越耗时；且该写法耦合HTML结构，语义脆弱。
为什么浏览器匹配 .card .header .title 这种写法特别慢
因为 CSS 选择器是「从右往左」匹配的。写 .card .header .title，浏览器先找所有 .title 元素，再逐个向上检查父级是否为 .header，再检查它的父级是否为 .card。DOM 节点越多、层级越深，回溯路径就越长。实测中，5 层嵌套在低端安卓设备上 Recalculate Style 时间可比单类名高 4 倍以上。
更麻烦的是：这类选择器天然耦合 DOM 结构。一旦把 .header 改成 .section，整条规则就静默失效，且很难被测试或工具发现。
为什么 .card__header__title 是非法 BEM 类名，不是手误而是语义错误
.card__header__title 看似只是多了一个 __，但它实际声明了三层归属关系：title 属于 header，header 属于 card。而 BEM 的核心约束是——Element 必须直属于 Block。一旦出现第三个 __，就等于把 card__header 当作新 Block 使用，但 card__header 本身只是 Element，没有独立语义边界和复用能力。
这会导致：
- 无法单独复用
.card__header__title：它绑死了 DOM 路径，抽到用户列表页就失效 - SCSS 中写
&__header { &__title { } }会编译出非法类名，还容易误给card__header加 padding，破坏 Element 的纯展示职责 - 改
card__header结构（比如换成card__section）时，所有依赖它的样式悄无声息崩塌
哪些地方还允许嵌套？必须满足什么条件
完全禁用嵌套不现实，但合法嵌套仅限三类场景，且必须锁死在 Block 边界内：
- 媒体查询：
.card { @media (min-width: 768px) { &__title { font-size: 1.2em; } } } - 伪类状态：
.btn { &:hover { &--primary { background: #007bff; } } }（注意：修饰符仍要挂载在 block 上，不能脱离） - 主题切换：
@layer theme { .card { @media (prefers-color-scheme: dark) { &__title { color: #fff; } } } }
关键约束：嵌套深度 ≤ 2 层，且所有嵌套都必须以 & 开头，确保编译后仍是单类名，不生成空格分隔的选择器。
SCSS 里怎么写才不踩坑
最危险的不是写错符号，而是嵌套逻辑掩盖了语义退化。常见误写：
-
.card { &__header { .title { } } }→ 编译出.card__header .title，后代选择器，BEM 封装失效 -
.card { &__header { &__title { } } }→ 编译出.card__header__title，三级命名，违反 BEM 核心定义 -
.card { .header .title { } }→ 完全脱离&，彻底放弃 BEM 拼接机制
正确做法只有一条：每个 Block 独立文件，根选择器只写一个块名；所有元素和修饰符都靠 &__xxx 或 &--xxx 显式拼接；想加“子元素的子元素”？先问一句：这个节点有没有自己的功能边界？能不能在别处复用？ 如果答案是肯定的，它就不该挂在父 Block 下，而该拥有自己的 block__element 结构。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
