参数化Mixin应聚焦设计系统级变量和语义化业务参数，避免过度参数化与冗余嵌套；优先封装稳定高频样式组合，用Guard条件设默认值，引入全局变量确保主题可维护。
Less参数化Mixin怎么写才不重复造轮子
直接说结论：参数化Mixin不是为了炫技，而是把「可能变」的值抽出来，让样式规则只定义一次，改一处就全局生效。关键在识别哪些是真变量——比如border-radius、transition-duration、主题色阶，而不是把每个按钮都塞一个.btn-primary和.btn-secondary硬编码进去。
常见错误是把所有样式属性都参数化，结果Mixin调用时传七八个参数，比直接写CSS还难读。真正该参数化的，是那些在多个组件间共享、且未来大概率要统一调整的值。
- 优先参数化设计系统级变量：如
@spacing-xs、@color-brand、@easing-standard - 组件级Mixin只暴露业务语义参数，比如
.card(@shadow: true, @rounded: true)，而不是.card(@box-shadow, @border-radius, @padding) - 避免在Mixin里做条件判断（如
when (@size = large)），除非该分支确实高频复用；否则逻辑会迅速失控
为什么用.button()比写一堆.btn-*类更可控
因为CSS类名爆炸是维护性杀手。写十个按钮变体，就得维护十个类、十套hover/focus状态、十个响应式断点逻辑。而一个.button()Mixin能收口所有基础行为，再通过参数组合生成差异。
使用场景很明确：当你发现三个以上组件共用同一组过渡动画或阴影规则，或者设计师给了一套间距/圆角数值表，就该上Mixin了。
-
.button(@variant: default, @size: medium)—— 用语义参数代替具体值，后续加danger或small不用新增类名 - 内部用
@import引入variables.less，确保@color-text等全局变量实时同步，不硬编码#333 - 别在Mixin里写
!important，它会破坏后续覆盖能力；真需要强制，用更具体的父选择器替代
参数默认值设错会导致编译失败或样式错乱
Less对参数类型不校验，.card(@shadow)如果没设默认值，调用时漏传就会报错variable @shadow is undefined；但设成@shadow: false又可能让box-shadow: false这种无效值进CSS。
正确做法是用Guard条件配合有意义的默认值，让“不传”等于“关”，“传true”才开。
- 写成
.card(@shadow: false) when (@shadow = true) { box-shadow: 0 2px 8px rgba(0,0,0,0.1); } - 颜色参数用
@color: @color-primary，而不是@color: #007bff，保证主题切换时自动更新 - 数值类参数带单位，如
@padding: 12px，避免调用时传12导致单位丢失
嵌套Mixin和循环容易让CSS体积失控
用.theme-variants()配合.for()循环生成深色/高对比模式，听着很酷，但实际会产出大量冗余选择器。Less编译后没法Tree-shake，没被调用的Mixin代码照样进最终CSS。
性能影响比想象中大：一个含5个状态的按钮Mixin，若被10个组件调用，可能生成50+行重复CSS；而用CSS自定义属性方案，体积可减少60%以上。
- 只对「稳定高频」的组合做Mixin封装，比如
.input-group()这种固定结构 - 避免用
.loop()生成状态类（如.is-valid、.is-invalid），这类应由JS控制class切换 - 用
npm run lessc -- --strict-math=on开启严格计算，防止@size * 2这种表达式在未定义时静默失败
复杂点在于：参数化不是越细越好，也不是越多越灵活。真正难的是判断哪一层该抽象——这得看团队协作节奏和设计系统演进阶段，而不是看Less文档写了几个高级语法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
