Less中extend是编译期选择器合并而非运行时继承，不支持伪类目标、参数或变量访问，适用于语义稳定的原子类；误用会导致循环警告、调试困难及IE8兼容问题。
Less中extend不是CSS继承，别当伪类用
Less的extend本质是编译期选择器合并，不是运行时样式继承。它不会生成父元素样式，也不会影响DOM结构或层叠顺序——只在编译后把匹配的选择器“抄一份”过去。常见错误是写成.btn:hover:extend(.btn)，结果编译报错：:hover是伪类，不能被extend目标直接匹配（目标必须是纯类名、ID或属性选择器）。正确做法是让被继承的基类本身包含状态：.btn { &:hover { ... } }，再用.special-btn:extend(.btn)。
什么时候该用extend而不是mixin
选extend的核心条件就一个：需要复用**选择器本身**，而不仅是样式声明。比如你有一套全局禁用规则.disabled，想让.form-input.disabled和.btn.disabled都挂上同一组禁用样式，且希望最终CSS里只出现一次.disabled的定义——这时extend能压缩体积；但如果你要传参数（如@color）、做逻辑判断或生成多套变体，就必须用mixin。extend不支持参数，也不支持嵌套作用域内的变量访问。
- 适合
extend：统一状态类（.hidden、.sr-only）、布局工具类（.clearfix） - 适合
mixin：带颜色/尺寸的组件变体、响应式断点封装、浏览器前缀补全 - 混用风险：
.a:extend(.b) { .c:extend(.b) }可能触发Less 4.0+的循环检测警告，实际不循环也会误报
extend的语法细节和兼容性坑
Less 3.5+开始支持all关键字，但默认只匹配顶层选择器。例如.nav-item:extend(.nav > li)不会生效，因为.nav > li含组合符；必须写成.nav-item:extend(.nav > li all)才能命中后代中的li。另外，extend对注释、空行敏感：如果被扩展的选择器前面有注释或空行，Less可能找不到它——建议基类集中放在文件开头，不加空行分隔。IE8及以下不支持CSS中多个逗号分隔的选择器共用同一套样式（这是extend编译后的产物），所以用了extend的项目基本放弃IE8支持。
- 必须加
all才能跨层级匹配：.sub-item:extend(.menu li all) - 不能扩展动态生成的选择器，如
.@{name}这种变量拼接形式 - Webpack + less-loader 7.x 默认开启
math=always，可能导致extend解析异常，建议显式设为math=strict
编译后CSS体积和维护成本的真实权衡
extend确实能减少重复CSS，但代价是选择器耦合度升高。比如.card:extend(.shadow-sm, .rounded)，一旦.shadow-sm定义改了，所有用到它的extend都会被动更新——这在大型项目里反而难追溯。更隐蔽的问题是调试：Chrome DevTools里看到.card的样式来自.shadow-sm，但点击跳转却定位不到源码（因为Less里没直接写.shadow-sm）。所以真正省代码的地方，其实是那些极少改动、语义稳定的原子类；高频迭代的业务组件，老老实实用mixin更可控。
立即学习“前端免费学习笔记（深入）”；
复杂点在于：extend的“复用”是静态的，它不关心上下文。当你以为在复用样式，其实是在复用选择器路径——这点稍不注意，就变成维护负担。
