extend未减少CSS体积的根本原因是被继承的选择器未真实输出，如通过@import (reference)引入的基础类不生成CSS，导致extend退化为声明复制。
为什么extend没减少CSS体积
很多人加了.btn-primary:extend(.btn all)后发现最终CSS还是臃肿，甚至更大。根本不是extend失效，而是它只在「目标选择器真实存在且未被移除」时才生效。如果.btn本身是通过@import (reference)引入的，它压根不输出——那extend就无处可继，编译器会退化成复制整套声明。
常见误用场景：
-
@import (reference) "base.less"里定义了.btn { ... }，但base.less里又@import "reset.css"（没加reference），导致reset.css样式照常输出，而.btn因reference被跳过——extend直接失效 - 多个文件都写
.btn:extend(.reset-button all)，但.reset-button只在某一个组件less里定义且未被@import (once)统一收口，结果各编译各的，生成多份重复块 - 用了
extend却还在同一文件里写了.btn { ... }，编译器不会合并，而是并存：一份来自extend继承，一份来自显式声明
extend必须搭配@import (once)才可控
extend不是独立优化开关，它依赖「被继承的选择器只出现一次、且确定输出」。否则，你写的:extend(.icon)可能在A文件里继承了.icon的规则，在B文件里又继承了另一份.icon（路径不同或导入方式不同），最终CSS里塞进两套几乎一样的样式。
安全做法：
立即学习“前端免费学习笔记（深入）”；
- 所有公共基础类（如
.sr-only、.clearfix）统一收进_extends.less，且只用@import (once) "_extends.less"引入 - 禁用
@import "components/*.less"这类通配导入——路径无法静态判定，(once)失效 - 检查编译后CSS里是否出现
.icon, .btn-icon, .menu-icon等并列选择器——这是extend成功合并的标志；如果只有.btn-icon { ... }单独成块，说明继承链断了
什么时候该用extend，而不是mixin
extend本质是选择器复用，mixin是声明复用。二者不能混用，选错就白忙活。
优先用extend的情况：
- 视觉上完全一致、仅类名不同的一组元素，比如
.close-btn和.delete-icon都应和.icon保持完全相同的尺寸、颜色、居中逻辑 - 需要被JavaScript精准获取的类名（如
document.querySelector('.icon')），用mixin会丢失语义类名 - 媒体查询内需继承响应式行为，例如
@media (max-width: 768px) { .mobile-nav:extend(.nav all) }，extend能连带继承.nav在该断点下的所有规则
别用extend的情况：
- 要传参（如
.btn(@size: md)），extend不支持参数，硬套会写死 - 继承目标含
&:hover或嵌套伪类，extend无法正确拼接&上下文，容易产出无效选择器 - 目标类本身带
!important或高权重要求，extend不提升权重，继承后可能被覆盖
extend在Webpack + less-loader里的隐藏陷阱
Webpack环境下，extend的行为受strictImports和缓存影响极大。一个看似正常的:extend(.visually-hidden all)可能在热更新后突然失效，原因往往藏在构建配置里。
关键检查点：
- 确保
less-loader开启strictImports: true，否则缺失.visually-hidden定义时只会静默跳过，不报错也不继承 - 禁用
javascriptEnabled: true时，extend无法解析JS表达式生成的选择器（如.@{ns}-hidden:extend(~".@{ns}-sr" all)会失败） - 若使用
cache: true，修改_extends.less后必须清掉node_modules/.cache，否则旧AST缓存会导致extend引用已删除的目标类 -
MiniCssExtractPlugin拆分CSS chunk时，如果.visually-hidden在chunk A，而.modal-close:extend(.visually-hidden all)在chunk B，两者加载顺序不确定，继承关系可能断裂
真正起效的extend链，必须从定义、导入、调用到打包，全程路径确定、无条件分支、不跨chunk边界——这点比语法本身更难控制。
