Less分层管理核心是变量和mixin必须抽离至variable.less和mixin.less，因其无作用域，全局可见，重复定义依赖导入顺序生效；组件文件禁止嵌套@import，须由入口统一按“重置→变量/mixin→基础组件→业务组件→页面定制”顺序导入，确保CSS层叠可控。
Less 的分层管理不是靠文件多就能解决的，核心是让变量、混合器、组件样式之间不互相污染，且编译后 CSS 的顺序可控——否则改个按钮颜色，结果被 base/reset 里一条 button { color: inherit; } 覆盖掉，根本查不到源头。
为什么变量和 mixin 必须单独抽成 variable.less 和 mixin.less
Less 没有作用域，所有 @import 进来的变量和 .mixin() 全局可见。如果把 @primary-color 写在 button.less 里，又在 card.less 里重定义一次，编译时不报错，但最终值取决于导入顺序，谁在后面谁生效。
- 所有基础原子值（颜色、间距、圆角、断点）只允许出现在
variable.less，命名带语义，比如@color-text-secondary，而不是@gray-3 -
mixin.less只封装纯逻辑，如.flex-center()、.text-ellipsis()，参数默认值必须引用变量，比如.border-radius(@radius: @radius-md) - 禁止在组件文件里
@import "variable.less"—— 入口统一导入一次就够了，否则 Webpack 的 less-loader 可能报Recursive import
组件样式文件为何不能直接 @import 变量或 mixin
常见错误：在 components/button.less 开头写 @import "../../styles/variable.less";。这会导致两个问题：一是路径随嵌套变深极易出错；二是破坏依赖流，你改了 variable.less，但构建工具可能没正确触发 button 文件的重新编译。
- 业务组件文件（如
button.less）只写样式规则，不负责引入依赖 - 每个组件目录下放一个
index.less，里面只做三件事：@import "variables";、@import "mixins";、@import "button"; - 根入口
styles/index.less按职责顺序导入：@import "base/index";→@import "components/index";→@import "pages/index";
如何确保按钮样式一定覆盖重置样式
CSS 层叠顺序 = @import 顺序。如果你在 index.less 里把 @import "components/button.less"; 放在 @import "base/reset.less"; 前面，那按钮样式先输出，重置规则后压上去，padding 和 border 就全没了。
立即学习“前端免费学习笔记（深入）”；
- 入口文件头部严格按「重置 → 变量/mixin → 基础组件（typography、grid）→ 业务组件 → 页面定制」顺序写
@import - 重置文件（
base/reset.less）只清margin、padding、font等默认值，绝不用!important锁死可覆盖属性 - 组件必须用命名空间类名，比如
.btn，而不是元素选择器button，避免和重置里的button { ... }直接竞争
嵌套超过三层时，为什么必须拆而不是硬撑
Less 嵌套本身不隔离作用域，.page { .section { .list { li { &:hover { .btn { ... } } } } } 编译出来是 .page .section .list li:hover .btn，不仅选择器权重高得离谱，而且一旦页面其他地方也有 .btn，照样被影响。
- 嵌套只用于表达明确父子/状态关系，比如
.dropdown { &:hover { .menu { display: block; } } } - 超过三层必须抽成独立 class，比如把深层逻辑提成
.dropdown-menu，再用.dropdown.is-open .dropdown-menu控制显隐 - 用
&__title这类 BEM 写法替代后代嵌套，输出.card__title，物理级隔离，不靠层级压权重
真正难的不是写多少层嵌套或建多少个文件，而是每次加一个新变量、写一个新 mixin、引入一个新组件时，能否立刻判断它该放在哪一层、由谁来导入、会不会悄悄覆盖别人——这种判断力，比语法本身重要得多。
