Less中应将按钮Mixin的尺寸和颜色作为参数抽离，尺寸用@size映射内部分量，颜色拆为@bg/@text/@border三参数，禁用态需兼顾可访问性与兼容性，避免无条件展开导致CSS冗余。
Less里怎么写按钮Mixin才不重复改样式
直接用参数控制尺寸和颜色，别为每个变体单独写一整套规则。核心是把变化的值抽成Mixin参数，固定结构只写一遍。
常见错误是把.btn-primary、.btn-small全写成独立类，结果改圆角要改12处，加新尺寸得复制粘贴再修5个地方。
- 尺寸参数建议用
@size统一传入：small、medium、large，内部映射成@padding-y、@font-size等变量 - 颜色参数拆成
@bg、@text、@border三个，避免用@theme这种模糊名，后期加暗色模式时容易冲突 - 别在Mixin里写
:hover伪类逻辑——它应该作为独立Mixin或嵌套块存在，否则调用时无法单独覆盖悬停色
为什么
不是Less编译问题，是CSS层叠顺序和选择器权重导致的。当.btn定义了background-color，而.btn--primary只是另一个独立类且没提高权重，浏览器按源码顺序渲染，后写的不一定赢。
使用场景：多人协作项目中，有人习惯用BEM命名，有人倾向原子类组合，混用时特别容易踩这个坑。
- 确保基础类
.btn只含通用结构（display、padding、border-radius），所有视觉样式由变体类接管 - 变体类必须比基础类权重高，比如用
.btn.btn--primary双类组合，或直接写.btn-primary单类 - 如果用
!important强行覆盖，后续维护者很难判断哪条规则该被删——少用
Mixin里怎么安全处理透明度和禁用态
直接写opacity: 0.6看似简单，但禁用按钮需要同时处理指针事件、焦点行为、颜色衰减，光靠CSS opacity会掩盖可访问性问题。
性能影响不大，但兼容性要注意：老版IE不支持RGBA，而fade(@color, 60%)生成的RGBA在IE9以下会退化成纯黑/白。
- 禁用态优先用
pointer-events: none+cursor: not-allowed，再叠加opacity - 颜色衰减别只靠
fade()，对深色背景上的浅色文字，应手动计算对比度，比如lighten(@bg, 20%)比单纯透明更可控 - 给
is-disabled属性加CSS属性选择器支持：[disabled], &.is-disabled，兼顾原生和JS控制的禁用
编译后CSS体积暴增，是不是Mixin用错了
是。每次调用.button-variant(...)都会生成一整套CSS规则，哪怕只改一个font-size，也会复制padding、border、transition全部代码。
真实场景：项目有8种颜色 × 4种尺寸 × 2种状态 = 64个组合，但实际页面只用其中不到1/5。
- 用
extract()或条件判断限制输出，比如when (@size = small) { ... }，避免无意义展开 - 把高频共用属性（如
transition: background-color .2s）提到.btn基础类里，变体只覆盖差异部分 - 如果项目已上CSS-in-JS或Tailwind，别硬套Less Mixin——工具链错配比写法错误更难调试
最常被忽略的是：Mixin不是万能胶，它解决的是“写得少”，不是“发得少”。最终CSS是否冗余，得看调用点是否真实存在，而不是编译前看着简洁。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
