能，less的extend语法在编译时合并css规则，不生成额外dom或class链；需写全选择器并加all才递归继承嵌套规则，不可跨文件未导入类引用，适用于无参样式归并而非动态逻辑。
Less的extend语法到底能不能替代重复类名？
能，但只在编译时生效，运行时不会生成额外DOM结构或class链。它本质是CSS规则合并，不是面向对象的“继承”。很多人误以为extend会像Sass的@extend一样智能推导选择器权重，其实Less更保守——它只做字面匹配和规则拼接。
- 必须写全选择器，
.btn无法被.btn-primary通过&:extend(.btn)捕获，得写成.btn-primary:extend(.btn all) -
all关键字很关键：不加时只继承同一级规则；加了才递归合并嵌套规则（比如.btn:hover） - 不能跨文件
extend未导入的类——必须先@import目标文件，否则编译报错Extend directive references selector that is not declared
什么时候该用extend，而不是Mixin？
核心区别在于是否需要参数化。Mixin适合带变量、可复用逻辑（比如.border-radius(@r: 4px)），而extend适合纯样式归并，且希望最终CSS体积更小。
- 按钮组统一禁用态：
.btn-disabled:extend(.btn all) { opacity: 0.5; cursor: not-allowed; }→ 编译后所有.btn规则会和.btn-disabled共用声明块 - 如果要动态控制圆角值、阴影深浅，就必须用Mixin，
extend没法传参 - 性能上，
extend在编译期展开，无运行时开销；但过度使用会导致CSS选择器爆炸（比如10个类都extend同一个基础类，最终生成10条重复规则）
extend遇到嵌套选择器容易出什么错？
Less的嵌套+extend组合极易产生意外匹配，尤其是当父选择器没写全时。
- 错误写法：
.modal { .header { color: #333; } }.title:extend(.header) {}→ 编译失败，因为.header不是顶层选择器 - 正确写法：
.modal { .header { color: #333; } }.modal .title:extend(.modal .header all) {}→ 必须带完整路径 - 更安全的做法：把可被继承的基础样式提成独立顶层类，比如
.text-emphasis，避免嵌套层级干扰
浏览器兼容性有没有坑？
没有。Less编译后就是普通CSS，extend本身不产生任何新语法，所有兼容性取决于你最终输出的CSS规则（比如用了gap或inset()才是真问题）。
- 唯一要注意的是：某些构建工具（如旧版webpack-less-loader）默认关闭
javascriptEnabled，若你在extend里用了JS表达式（不推荐），会报错 - 线上环境如果看到样式丢失，优先查Less编译日志，而不是浏览器兼容表——99%是选择器路径写错或
@import顺序反了
真正难搞的是语义收敛：当你有20个组件都extend同一个.clearfix，某天想改清除浮动方式，就得全局搜extend位置，比直接改一个Mixin麻烦得多。这点常被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
