先说几个核心判断：Less 的 Mixin 特性在小型项目中堪称神器，可一旦项目规模膨胀，它会悄悄演变成“隐式行为黑洞”——调用时不暴露依赖、传参完全靠默契、覆盖行为没有任何预警。这玩意儿越用越多，越改越让人心虚。系统地说，问题出在参数管理、作用域隔离和类名复用这三个维度上。
Mixin 参数膨胀导致调用失控
举个典型的例子。一个简单的 .button() Mixin，最初只有 2 个参数，随着业务演进变成 5 个：$size、$variant、$rounded、$disabled、$fullwidth。表面看是“写起来麻烦”的问题，实际隐患要深得多：
- 实际现象：
@include button(lg, danger, true)中第三个true代表“圆角”还是“禁用”？调用时顺序错一位、漏传一个、默认值不一致，编译器都不报错，但生成的 CSS 行为已经不可靠了——比如某个.btn-lg.danger的圆角莫名消失，控制台却一片寂静，根本找不到是哪行代码覆盖了border-radius - 根本原因：参数靠位置绑定，没有类型校验，也没有键名语义。新成员接手这个 Mixin，面对
@include button(lg, danger, true)，完全不敢删改任何一个参数 - 正确做法：改用 Map 参数。例如
@include button(("size": "lg", "variant": "danger", "rounded": true))，内部用map-get($config, "rounded")取值，再加上默认值兜底。这样调用时语义清晰，扩展起来也安全
Mixin 依赖不显式，破坏作用域隔离
Less 没有模块作用域，@import 本质上就是文本拼接。这个设计在大型项目中会引发连锁反应。
比如 components/card.less 和 pages/home.less 都直接 @import "mixins/flex-center"，而这个 Mixin 文件里又引用了 @primary-color。那它就强依赖 variables.less 的导入顺序——谁先谁后，决定了变量取哪个值。
- 典型错误：
mixins/flex-center.less里写了background: @primary-color，但没声明@import "../variables"，全靠父级文件间接带入；一旦父级重构，立刻报Variable @primary-color is undefined - 解决方式：所有只提供逻辑的 Mixin 文件，必须用
@import (reference) "variables"显式声明依赖，且不输出 CSS；业务文件永远不直接@import深层 Mixin，只通过模块index.less统一暴露 - 别名配置要跟上：Webpack 或 Vite 中配
resolve.alias["@mixins"] = "src/styles/mixins"，避免../../../mixins这种路径爆炸
辅助类名泄漏到 HTML，破坏样式封装
像 .flex-center、.text-ellipsis 这类通用类，表面省事，实则让组件样式不再自包含。一旦设计规范要求“所有卡片标题截断改为两行”，你就得全局搜 class="text-ellipsis"，手动判断哪些该改、哪些不该改——更隐蔽的问题是，这类类名常被写进 Vue/React 组件的模板里，等于把样式决策权交给了使用方，而不是定义方。
- 推荐替代方案：用参数化 Mixin，比如
.text-line-clamp(@lines: 1)，在组件自己的 Less 文件里调用。HTML 保持语义化，样式变更只改一处 - 如果真需要通用类：务必限定作用域：
[data-role="card"] .text-ellipsis，而不是全局.text-ellipsis
Mixin 不是“多写几个 .xxx() 就叫复用”。真正的维护成本藏在三个地方：调用链路是否可追溯、参数是否可演进、依赖是否显性。项目越大，越不能靠“大家自觉不乱用”来维系，必须靠结构约束和工具链兜底。
