extend 必须加 all 才能继承嵌套规则，否则仅合并顶层声明；不跨文件生效，依赖 @import 顺序；组合嵌套易致选择器爆炸；改变权重且隐藏样式来源，调试困难。
extend 必须加 all 才能真正继承嵌套规则
不加 all 时，.btn-primary:extend(.btn) 只会合并 .btn 自身的顶层声明，像 .btn:hover、.btn.is-active 这类嵌套生成的选择器压根不会被拉进来。结果就是：按钮正常态样式有了，悬停态却完全丢失——表面看编译没报错，实际运行时交互失效。
常见错误写法：.icon-warning:extend(.icon)；正确写法：.icon-warning:extend(.icon all)。只有加了 all，编译器才会递归扫描 .icon 下所有嵌套路径（包括伪类、属性选择器、子代组合器），并把它们一一与扩展者拼接。
- 不加
all→ 仅匹配字面选择器，安全但残缺 - 加
all→ 匹配全部衍生选择器，完整但易爆炸 - 调试技巧：临时删掉
all，对比编译前后 CSS 文件大小和选择器数量，能立刻看出是否漏了状态
extend 不跨文件生效，@import 顺序决定一切
extend 是静态解析，只在当前编译上下文里找已声明的选择器。你在 components.less 里写 .card:extend(.flex-center)，但 .flex-center 定义在 utils.less 里，又没提前 @import "utils.less"，那这条 extend 就是静默失效——不报错，也不产出任何 CSS。
更隐蔽的问题是：如果 utils.less 被 @import (reference) 引入，它只提供 mixin 和变量，不输出 CSS，那么其中定义的 .flex-center 在编译期根本“不存在”，extend 同样找不到。
立即学习“前端免费学习笔记（深入）”；
- 必须确保目标选择器出现在
extend语句之前，且未被@media、@supports或嵌套块隔离 - 基础工具类（如
.sr-only、.clearfix）建议集中放在一个非reference的入口文件里，统一导入 - Webpack 中若用
less-loader+postcss-import，注意两者@import行为不兼容，优先用后者处理跨文件依赖
嵌套 + extend 组合极易触发选择器爆炸
Less 允许你这样写：.card { &__header:extend(.flex-center all) {} &__body:extend(.flex-center all) {} }。看起来干净，但编译后，.flex-center 的每一条规则（包括 .flex-center:hover、.flex-center.is-active、.flex-center > span）都会分别跟 .card__header 和 .card__body 组合，生成双倍冗余选择器。
当多个组件都 :extend(.base-layout all)，而 .base-layout 本身又有 5 层嵌套时，最终 CSS 里可能出现上百条看似无关实则重复的选择器，体积翻倍，浏览器解析变慢，DevTools 里也难以定位来源。
- 避免在深度嵌套结构中使用
extend，尤其别在&__item这类 BEM 子类上直接 extend - 如果基类本身含大量伪类或后代组合器，宁可用
.mixin-flex-center()显式调用，可控性更强 - 用
lessc --lint或自定义 ESLint Less 插件，可检测出高风险的extend嵌套层级
extend 改变选择器权重，调试时很难回溯样式来源
.btn:extend(.disabled) 编译后生成的是 .btn, .disabled { opacity: 0.5; }。这意味着 .btn 的权重被强行拉高到和 .disabled 一致。如果 .disabled 本身带 !important 或来自高权重选择器（如 body .disabled），那 .btn 也会被动继承这套权重逻辑，导致后续覆盖异常困难。
更麻烦的是：Chrome DevTools 里点开 .btn 样式，看到的来源可能是 utils.less:12（即 .disabled 定义处），而不是你写 extend 的那个文件。样式来源“消失”了，只剩一串合并后的选择器，调试成本陡增。
- 不要用
extend去复用带!important或复杂权重的选择器 - 团队协作中，对所有
extend使用加注释说明用途，例如：// extend .text-muted to share color reset, not for weight inheritance - 大型项目里，
extend应严格限制在原子类（如.hidden、.visually-hidden）上，禁用在业务组件类之间互相 extend
extend 的“全匹配”不是智能推导，而是机械拼接。它不管语义是否合理，只管字面是否存在。一旦基类重构、重命名或拆分，所有 extend 它的地方都会悄悄失效，直到某天某个 hover 态突然不工作了才被发现。 
