Less 中 extend 用于编译时合并选择器以减少 CSS 体积，需加 all 才继承嵌套规则；不支持跨文件、参数化及深层嵌套，易导致选择器爆炸；适用样式身份固定场景，动态或差异化需求应选 mixins；大型项目须收敛入口、统一命名并强制约束。
Less 中用 extend 实现样式复用，不是为了偷懒，而是避免重复编译
extend 的本质是让编译器在生成 CSS 时把多个选择器合并到同一份声明块里，而不是复制粘贴样式。它不像 mixins 那样每次调用都插入完整规则，所以最终 CSS 文件更小、浏览器解析更快。
常见错误现象：.btn:extend(.base-style all) { } 写成 .btn:extend(.base-style) { } —— 少了 all，就只继承直接匹配的选择器，嵌套规则（比如 .base-style:hover）压根不会被拉进来。
使用场景：
- 组件库中定义基础语义类（如
.text-primary、.border-solid），再让具体组件类继承它们 - 避免为每种按钮状态（
.btn-primary、.btn-danger）重复写display: inline-flex; align-items: center;这类共性
注意点：
立即学习“前端免费学习笔记（深入）”；
-
extend只能在选择器层级生效，不能在mixins或变量内部使用 - 不支持跨文件直接
extend，必须确保被继承的选择器已在当前作用域或已通过@import加载 - 如果被继承的选择器带参数（比如
.bg(@color)），extend无能为力——这时得换mixins
继承链太深会让 CSS 选择器爆炸，尤其和嵌套一起用
Less 允许嵌套 + extend，但编译器会把所有组合路径展开。比如：
.card {
&__header:extend(.flex-center all) {}
&__body:extend(.flex-center all) {}
}
实际输出的 CSS 里，.flex-center 的所有变体（包括 .flex-center:hover、.flex-center.is-active）都会分别跟 .card<strong>header</strong> 和 .cardbody 组合，生成一堆冗余选择器。
性能影响：
- 浏览器 CSSOM 构建变慢，尤其在低端设备上
- DevTools 里调试时看到的选择器长到看不清来源
建议做法：
- 单层继承优先：让
.card<strong>header</strong>直接:extend(.flex-center all)，别套在&header里再 extend - 把需要批量继承的基础类单独抽成一个
base.less，不参与深层嵌套 - 编译后用工具（如
cssnano）做选择器合并，但别依赖它来补救设计问题
用 extend 替代 mixins 前，先确认是否真需要“样式归属权”
mixins 是复制规则，extend 是共享规则。区别在于：如果某个样式将来要单独修改（比如只改 .btn-primary 的边框圆角，不影响其他继承者），那就不能用 extend —— 因为所有继承它的选择器都共用同一份声明，改一处全改。
容易踩的坑：
- 把
.icon:extend(.inline-block all)和.avatar:extend(.inline-block all)写在一起，结果某天想给.icon加vertical-align: middle，却发现加在.inline-block里会影响.avatar - 在主题切换场景下，用
extend继承颜色变量类（如.text-light:extend(.text-default all)），但主题变量是运行时 JS 控制的，而extend是编译时行为，根本没法动态响应
判断依据很简单：
- 如果这个样式“身份”是固定的（比如所有图标都要是
inline-block，且永远不变），extend更干净 - 如果这个样式未来大概率要差异化（比如不同组件对
cursor、transition有各自要求），老实用mixins或原子类
构建样式库时，extend 的入口必须收敛，否则维护成本指数上升
大型项目里，extend 被到处乱用会导致“谁继承了谁”完全不可追溯。你改一个基础类，可能连测试都没跑就炸了三个页面的布局。
实操建议：
- 所有可被
extend的基础类统一放在src/styles/base/extends.less，命名带前缀，比如.x-flex-center、.x-text-sm，避免和业务类名冲突 - 禁止在业务组件文件里定义可被继承的选择器；只允许引用，不允许新增
- CI 中加入检查：用正则扫描
:extend((?!x-)，发现非约定前缀的 extend 调用就报错
最麻烦的地方其实是人：团队里只要一个人在组件里随手写个 .my-hack:extend(.clearfix all)，后面所有人就得猜这个 .my-hack 到底还干了啥。样式库的约束力，不体现在语法多强大，而在于边界划得够不够狠。
