Less通过变量和Mixin集中管理样式原子值与行为，配合分层目录、统一index入口及Webpack别名配置，可有效避免重复定义与隐式依赖问题。
Less变量与Mixin如何避免样式重复定义
大型项目里，颜色、间距、字体这些基础值一旦散落在多个文件中，改一个主题色就得全局搜替换，极易漏改或误改。Less的@variables和.mixin()是第一道防线。
实际做法是把所有可复用的原子值收敛到variables.less，比如@primary-color: #007bff;；把通用行为（如弹性布局居中、响应式断点）封装成.flex-center()或.media-breakpoint-down(md)，放在mixins.less里。
- 变量命名要带语义，别写
@c1或@gray-3，优先用@color-text-secondary这类表达用途的名称 - Mixin里避免硬编码值，全部引用变量，比如
.border-radius(@radius: @border-radius-default) - 不要在组件文件里重新定义同名变量——Less不会报错，但后续导入顺序会导致覆盖，值不可预期
为什么必须用Index文件统一管理导入顺序
Less不支持循环依赖，但更常见的是“隐式依赖”：某个组件样式用了.btn的Mixin，却没显式@import它，靠父级文件间接引入。一旦目录结构调整，编译就报Undefined mixin或Variable is undefined。
标准解法是在每个模块目录下放一个index.less，只做两件事：声明本模块对外暴露的样式入口、明确声明依赖项。
立即学习“前端免费学习笔记（深入）”；
-
components/button/index.less里只写：@import "variables"; @import "mixins"; @import "button"; - 根目录
styles/index.less按分层顺序导入：@import "base/index"; @import "components/index"; @import "pages/index"; - 业务页面文件（如
pages/dashboard.less）永远只@import "../index";，不直接导入深层路径
分层目录结构该按什么维度切分
不是按“功能模块”（如user、product），而是按样式职责分层。层级越靠上，抽象度越高、复用性越强、变更频率越低。
-
base/：重置样式、默认字体、基础变量、工具类（.sr-only、.visually-hidden） -
layout/：栅格系统、容器宽度、页眉页脚、侧边栏折叠逻辑等全局布局规则 -
components/：按钮、输入框、卡片、模态框等独立UI单元，每个组件自含index.less -
pages/：仅处理页面级特有样式（如.dashboard-header），禁止写通用规则
注意：pages/下的文件不应被其他页面复用；如果发现两个页面共用某块样式，说明它其实属于components/或layout/，得往上提。
Webpack中Less导入路径别名怎么配才不踩坑
写@import "../../base/variables";这种相对路径，在嵌套深了之后极易出错。用Webpack的resolve.alias配别名是必须的，但配置方式直接影响维护成本。
- 推荐配成
{"@": path.resolve(__dirname, "src/styles")}，然后统一用@import "@/base/variables"; - 别配
{"styles": path.resolve(...)}再写@import "styles/base/variables";——Less的@import对路径别名支持不稳定，某些版本会忽略别名或报Cannot resolve - 确保
less-loader开启javascriptEnabled: true（仅当需要动态计算变量时），否则evaluate函数无法使用，且存在安全风险，非必要不启用
真正难的不是搭结构，而是坚持让每个新成员都往variables.less里加颜色、而不是随手写#4a5568；也不是写对@import路径，而是每次删组件时，同步清理它在所有index.less里的引用行——没人检查，就等于没结构。
