Mixin易成隐式行为黑洞，因参数无类型校验、依赖不显式、覆盖无提示；应改用Map参数+显式@import(reference)+作用域限定类名来保障可维护性。
因为 Mixins 容易变成“隐式行为黑洞”——调用时不暴露依赖、参数无约束、覆盖无提示，越用越多，越改越怕。
Mixin 参数膨胀导致调用失控
当一个 .button() Mixin 从 2 个参数变成 5 个（$size, $variant, $rounded, $disabled, $fullwidth），问题就不是“写起来麻烦”，而是调用时顺序错一位、漏传一个、默认值不一致，编译器都不报错，但生成的 CSS 行为已不可靠。
- 实际现象：
.btn-lg.danger圆角消失，但控制台没报错，也找不到哪行代码覆盖了border-radius - 根本原因：参数靠位置绑定，没有类型校验，也没有键名语义，
@include button(lg, danger, true)中第三个true到底代表什么？没人敢删 - 正确做法：改用 Map 参数，比如
@include button(("size": "lg", "variant": "danger", "rounded": true))，内部用map-get($config, "rounded")取值，加默认值兜底
Mixin 被多处直接 @import，破坏作用域隔离
Less 没有模块作用域，@import 是文本拼接。如果 components/card.less 和 pages/home.less 都直接 @import "mixins/flex-center"，而这个文件里又引用了 @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写到路径爆炸
无区分地复用 .helper-class 类名，把样式逻辑泄漏到 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() 就叫复用”，它真正的维护成本藏在调用链路是否可追溯、参数是否可演进、依赖是否显性这三个地方。项目越大，越不能靠“大家自觉不乱用”来维系，必须靠结构约束和工具链兜底。
