less中不存在抽象类，其对应需求应通过参数化mixin、when条件分支、命名空间隔离实现；必须避免全局变量默认值污染、隐式耦合及未完备分支导致的样式失效。
Less 里没有“抽象类”这个概念——它不是面向对象语言，不存在 class 继承链或实例化逻辑。所谓“抽象类”的需求，实际对应的是 .mixin（混合器）的合理封装，配合 when 条件分支、参数默认值和命名空间隔离来实现样式逻辑的复用与收敛。
为什么不能直接套用 OOP 的抽象类思维
Less 编译发生在构建时，所有样式最终都扁平输出为静态 CSS。你写 .button() { ... } 不代表它“存在”于运行时，也不具备多态或重写能力。JS 动态加 class="btn-primary" 不会触发 Less 重新计算，.button(primary) 的结果早已固化在生成的 CSS 里。
常见误操作包括：
- 把
.card()当成可被子类 extend 的基类，结果发现.card-featured:extend(.card)只能继承已编译出的属性，无法动态注入新参数 - 在多个文件中重复定义同名
.icon()，未加命名空间，导致最后编译出的 CSS 里属性互相覆盖 - 依赖全局变量如
@bg-color作 mixin 默认参数，而该变量在别的 less 文件里被@bg-color: #fff覆盖，导致所有.card()意外变白底
用命名空间 + 参数化 mixin 模拟“抽象基类”行为
真正可控的做法是显式收口：把一组强相关样式逻辑封装进带前缀的 mixin，并强制调用者传参或使用明确的条件分支。
例如实现一个按钮系统：
.btn(@variant: default, @size: md) when (@variant = default) {
background: @gray-200;
color: @gray-800;
}
.btn(@variant, @size) when (@variant = primary) {
background: @primary-color;
color: #fff;
}
.btn(@variant, @size) when (@variant = outline) {
background: transparent;
border: 1px solid @primary-color;
color: @primary-color;
}
关键点：
- 每个
when分支必须完整声明所有相关属性，不能只写color忽略background，否则未匹配分支会静默失效 - 不写
when的兜底分支（如.btn(@variant, @size) { ... }）会导致未知@variant值时整个 mixin 不生效 - 调用必须显式：比如
.btn(primary, lg)，而不是靠 class 名自动映射
避免默认值污染：参数必须是字面量或纯函数结果
下面这种写法危险：
.card(@bg: @card-bg-color) {
background: @bg;
}
因为 @card-bg-color 是全局变量，一旦在别处被重赋值（比如主题切换文件里 @card-bg-color: #f0f9ff），所有未传参的 .card() 都会跟着变——这不是“继承”，是隐式耦合。
安全做法是：
- 默认值用字面量：
@bg: #f8f9fa - 或用内置函数确保确定性：
@bg: lighten(@primary-color, 40%)（前提是@primary-color本身也是字面量或稳定函数结果） - 真要复用设计变量，显式传参更清晰：
.card(@card-bg-color)，让调用点暴露依赖
样式泄漏问题：如何防止 .button() 影响全局选择器
直接写 .btn-primary { .button(primary); } 看似干净，但若另一个组件也定义了 .button()，它们会共用同一组编译后 CSS 规则，容易冲突。
推荐方案是用嵌套命名空间封装：
.ui-button {
&-primary { .btn(primary, md); }
&-outline { .btn(outline, sm); }
&-large { .btn(default, lg); }
}
这样生成的 CSS 是 .ui-button-primary、.ui-button-outline，天然隔离，不会和第三方 .button 类撞名。这也是最接近“抽象类实例化为具体子类”的工程实践。
真正容易被忽略的，是 when 分支的完备性和默认参数的稳定性——它们不像 JS 函数有运行时校验，错漏会在编译后才暴露为样式异常，且难以定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
