extend生成冗余选择器是因为它仅在目标与基类共存于同一编译上下文且语法完全匹配时才生效，否则静默失败、各自输出；常见失效原因包括跨文件未@import、伪类未加all、基类非顶层声明、变量拼接等。
为什么extend会生成冗余选择器
Less 的 extend 本质是编译期选择器字符串合并，不是运行时去重。它只在目标选择器与被扩展选择器**共存于同一编译上下文**、且语法完全匹配时才生效；否则静默失败，两个选择器各自输出——你看到的“重复”，其实是 extend 根本没跑起来。
常见失效场景包括：
– 跨文件未 @import 目标类（如 .btn-primary:extend(.btn) 但 button.less 没被导入）
– 目标选择器含伪类或组合符（如 .nav > li 必须写 :extend(.nav > li all)）
– 基类定义前有空行或注释，Less 解析器找不到声明
– 使用了变量拼接的选择器（如 .@{name}），extend 不支持动态解析
如何确保extend真正生效而非静默失败
关键不是“怎么写 extend”，而是“怎么让 extend 被看见”。必须满足三个硬性条件：
-
%placeholder或.base-class必须顶层独立声明，不能嵌套在其他规则块里 - 调用方文件必须通过
@import显式加载定义文件，且@import语句必须在:extend()之前 - 目标选择器要写全：想继承
.btn:hover，就得让基类本身定义.btn { &:hover { } }，再用.btn-primary:extend(.btn all)
验证是否生效最简单的方法：临时删掉基类定义，如果编译报错 Extend directive references selector that is not declared，说明之前是生效的；如果不报错，那它一直就没起作用。
立即学习“前端免费学习笔记（深入）”；
什么时候该停用extend，改用mixin或class组合
extend 不是万能的样式复用方案，它只适合一种场景：多个选择器**语义上等价、且你希望它们共享同一组 CSS 声明**。一旦出现以下情况，就该立刻放弃：
- 需要传参（比如不同颜色、尺寸、断点值）→ 改用
.button(@color, @size)mixin - 只想复用部分样式（比如只想要
display: inline-block，不想要基类的margin）→ 改用原子 class 组合（class="btn inline-block"） - 基类本身权重高（如
.disabled是 0-1-0），:extend(.disabled)会把高权重“传染”给所有扩展项，后续覆盖更难 - 项目需兼容 IE8（
extend编译后生成逗号分隔的选择器列表，IE8 不支持）
尤其注意：Webpack + less-loader 7.x 默认 math=always，可能导致 extend 解析异常，建议显式配置 math=strict。
占位符选择器（%）比普通类更可控，但有严格限制
% 占位符是减少冗余的更安全选择，因为它默认不输出 CSS，只在被 :extend() 调用时才注入。但它有不可妥协的约束：
- 必须顶层声明：
%icon-reset { display: inline-block; }✅；.btn { %icon-reset { } }❌（嵌套报错） - 不能带参数、不能访问外部变量、不能嵌套调用（
%a:extend(%b)在旧版 Less 中可能穿透失败） - 跨文件使用时，
@import顺序不能颠倒，且不能加(reference)（否则不会被识别为可 extend 目标） - 编译后选择器权重不变，但一旦多个类都
:extend(%text-truncate)，最终 CSS 里会出现.title, .subtitle { overflow: hidden; ... }—— 这不是 bug，是你本意就是让它们共用规则
真正容易被忽略的是：extend 合并后，选择器耦合度升高。比如 .card:extend(.shadow-sm, .rounded)，只要 .shadow-sm 定义一改，所有 extend 它的地方都会被动更新，而这种依赖关系在代码里完全不可见。
