Less不支持自动模拟BEM嵌套，唯一可靠写法是&__element生成.block__element；修饰符必须作用于块级；嵌套超两层会升高权重、降低性能；应手动定义块名或直接手写，而非依赖extract()等脆弱方法。
Less 本身不支持“模拟 BEM 嵌套”——它没有运行时 DOM 意识，也无法自动推导块名；所谓“模拟”，本质是用 & 和固定命名约定，手动写出符合 BEM 规范的 CSS 类名。强行让 Less “猜”块名，只会产出不可靠、难调试的选择器。
为什么 &__element 是唯一可信赖的写法
& 在 Less 中代表**紧邻上一级选择器的完整字符串**，不是“类名前缀”。只有 &__element 这种写法能稳定生成 .block__element（权重 0-1-0），语义清晰、可复用、支持组合。
-
.card { &__header { color: #333; } }→ 编译为.card__header，正确 -
.card { .header { &__logo { } } }→ 编译为.card .header .card__logo，多出无意义层级，破坏 BEM 原子性 -
.card { & .header { } }→ 编译为.card .header，后代选择器，高权重、不可独立使用
&--modifier 必须绑定到块级，不能作用于元素
BEM 修饰符（--）描述的是**块的整体状态**，不是某个子元素的状态。把修饰符写在元素上，会切断组合能力。
- ✅ 正确：
.card { &--featured { background: #f5f5f5; } &__title { font-weight: bold; } }→ 可组合为.card--featured .card__title - ❌ 错误：
.card { &__title--large { } }→ 编译为.card__title--large，无法与.card--featured共存，且违背 BEM 约定 - ⚠️ 高危：
.btn { &:hover { &__icon { } } }→ 编译为.btn:hover .btn__icon，权重飙升，且 hover 状态本应由.btn--primary:hover这类块级修饰符控制
嵌套超过两层就该警惕：它正在生成高权重 CSS
每多一层缩进，Less 就多拼一个空格分隔的父选择器，最终生成的是后代选择器（如 .a .b .c），权重和匹配成本直线上升。
立即学习“前端免费学习笔记（深入）”；
-
.modal { .body { .content { padding: 1rem; } } }→ 编译为.modal .body .content（权重 0-3-0） - 浏览器匹配时需从
.content往上逐层回溯，DOM 深了就慢；后续覆盖必须写成.modal .body .content.is-expanded或加!important - 真正解法是扁平化：
.modal__content { padding: 1rem; }，再用&--scrollable控制变体
别用 extract() 或 replace() 提取块名
Less 是编译期工具，没有 DOM 上下文。所谓“自动提取”，依赖 extract(&, 1) 取第一个选择器，但前提是父级必须是单个类（如 .card）。一旦写成 .container .card，extract(&, 1) 就返回 .container，直接崩。
- 这种写法脆弱、不可读、IDE 无法提示，且绕过 BEM 工具链（如 lint、postcss-bem-linter）
- 团队协作中，有人改 HTML 结构（比如加了个 wrapper），所有依赖
extract的样式就失效 - 真正可控的方式：人为定义
@block: ~".card"，再用@{block}__header，或——更推荐——直接手写.card { &__header { } }
最易被忽略的一点：BEM 不是 Less 技巧问题，而是 HTML + CSS + 团队契约的协同结果。一个 .card__header 元素，如果在 HTML 里被塞进 <div class="page__main"><div class="card">...</div></div>，那它就该保持独立可用；若你非得靠 .page__main .card .card__header 才生效，说明 BEM 已经失效——这时候修 Less 语法，不如先修组件结构。
