less mixin 重名会静默覆盖，后定义的生效；@import (reference) 不隔离作用域，仍会导致冲突；应强制加前缀、参数化统一入口、单点收口 mixins.less。
Less mixin 重名会静默覆盖，不是报错而是“后定义的生效”
Less 的 mixin 没有命名空间或模块作用域，同名 mixin 在编译时按 @import 顺序线性处理：后出现的会完全替换前面定义的，且不报任何警告。比如你在 buttons.less 里写了 .size() { font-size: 14px; }，又在 typography.less 里写了同名 .size() { font-size: 16px; }，那么所有调用 .size() 的地方最终都用 16px——哪怕你本意只给按钮用小字号。
为什么用 @import (reference) 也不能防 mixin 冲突
@import (reference) 只抑制 CSS 输出，但变量和 mixin 仍会被注入当前作用域。它不创建隔离环境，只是“不生成样式”。如果你在多个 (reference) 文件中都定义了 .clearfix()，最后加载的那个会生效，其余被覆盖。
- 错误假设：
@import (reference) "mixins-btn.less"; @import (reference) "mixins-form.less";→ 认为两者互不干扰 - 实际结果：后者里的
.clearfix()覆盖前者，调用时行为统一 - 真正安全的做法：每个
(reference)文件只暴露带前缀的mixin，如.btn-clearfix()、.form-clearfix()
解决 mixin 命名冲突的三个实操动作
核心原则是“不依赖全局命名，而靠显式命名 + 显式调用”：
- 强制加前缀：
.btn-size(@s: md)、.form-label-color(@c)，杜绝裸名.size()或.label() - 用参数化替代多版本同名：
.btn-style(@type: default, @size: md)一个入口，守卫条件分支，而不是写.btn-primary()、.btn-secondary()多个独立mixin - 禁止跨文件重定义同一
mixin名；若必须复用逻辑，把基础mixin放进mixins-core.less，其他文件只@import它，不再重写
容易被忽略的构建陷阱：Webpack less-loader 并行解析
Webpack 默认可能并发处理多个 Less 入口（比如多个页面级 .less），导致 variables.less 和 mixins.less 被多次加载、变量与 mixin 被反复注入，最终以最后一次解析为准——这比顺序错误更难调试。
- 现象：
npm run build有时样式对，有时错，本地开发却稳定 - 检查点：less-loader 配置是否用了
additionalData或modifyVars，它们可能绕过@import顺序 - 稳态方案：所有公共
mixin必须收口到单个mixins.less，且在每个入口文件顶部第一行@import "mixins.less";，不依赖构建工具自动注入
mixin 后，散落在七八个组件里的调用点全被悄悄改了行为，还查不到源头。这种静默覆盖没法靠 lint 捕获，只能靠命名约定和构建约束卡死。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
