Less分层应按职责划分为variables、mixins、components/pages三层，入口统一导入避免重复；禁用@import(reference)于业务组件；嵌套不超过3层；变量须带作用域前缀并慎用!default。
Less导入机制怎么分层才不混乱
直接用 @import 把所有样式一股脑塞进一个入口文件，很快就会失控——修改一个按钮样式，要翻五六个文件，还总搞不清哪个变量被谁覆盖了。分层的关键不是“多建几个文件”，而是按职责切，且每层只暴露它该管的东西。
-
@import默认是顺序拼接，没有作用域，所以变量和 mixin 在导入链里是全局可见的；想隔离？得靠.less文件的命名约定 + 显式控制导入顺序 - 推荐三层结构：
variables.less（仅定义基础色、间距、断点）、mixins.less（仅封装.flex-center()、.text-ellipsis()这类纯逻辑），最后才是components/和pages/下的具体样式 - 避免在
components/button.less里再@import "variables"—— 入口文件统一导入一次就够了，否则变量重复声明会静默覆盖，而且 Webpack 的 less-loader 可能报Recursive import
为什么 @import (reference) 不能乱用
看起来很美：不输出 CSS，只让 mixin 和变量可用。但实际项目里，它会让调试变得反直觉——你改了 mixins.less 里的 .clearfix()，却发现某个组件的浮动没清掉，因为它的样式根本没被 @import (reference) 引入过，或者被别的 @import 覆盖了优先级。
-
@import (reference)后，文件内定义的 class 选择器完全不会编译进最终 CSS，只有 mixin 和变量可调用；适合放通用工具集，不适合放业务组件样式 - 如果某个
components/card.less依赖mixins.less里的.shadow-sm()，又想复用card的样式规则，就别用(reference)导入 mixins —— 改成普通@import，并在入口统一管理依赖流 - Webpack 环境下，
less-loader对(reference)的缓存处理不稳定，有时热更新后 mixin 不生效，重启 dev server 才行
嵌套层级深了，CSS 输出爆炸怎么办
Less 的嵌套写法省事，但一个 .page-home 套三层选择器，再加伪类和媒体查询，生成的 CSS 选择器可能变成 .page-home .section .list li:hover .btn:active —— 不仅体积大，还容易被更高权重的选择器意外覆盖。
- 嵌套只用于表达明确的父子/状态关系，比如
.dropdown { &:hover { .menu { display: block; } } }；不要为了“看起来整齐”把所有同级模块都塞进一个父选择器里 - 用
&显式拼接时注意空格：&.is-active编译为.btn.is-active，& .icon才是后代选择器；少打一个空格，样式就跑偏 - 超过 3 层嵌套必须拆：把深层逻辑抽成独立 class，比如把
.modal .content .form .input-group input改成.form-input，然后在 JS 或模板里加类
变量命名冲突和覆盖的真实场景
两个人同时改 variables.less，A 提交了 @primary-color: #007bff;，B 提交了 @primary-color: #0d6efd;，合并后只剩后者——但 B 不知道 A 在 components/alert.less 里用了这个变量做背景，结果所有 alert 都变色了，还没报错。
立即学习“前端免费学习笔记（深入）”；
- 变量名必须带作用域前缀：
@btn-primary-bg、@alert-border-width，而不是笼统的@primary或@border - 用
!default要谨慎：@spacing-md: 16px !default;看似安全，但如果某处提前声明了@spacing-md: 24px;，后面再用!default就无效了——它只在首次声明时起作用 - CI 流程里加一条检查：用正则扫
@.*:出现次数，同一变量在多个文件中直接赋值（非!default）就报警
真正难的不是写 Less，是让团队所有人对「哪些该抽、抽到哪一层、谁负责维护」有共识。变量命名规则、导入顺序、嵌套深度，这些地方一旦松动，三个月后就没人敢动核心样式了。
