Less代码规范通过强制编译期规则降低维护成本：变量必须前置且全局唯一、@import顺序不可错乱、嵌套不超过三层，这些硬性约束显性化隐性依赖，提升可维护性。
Less 代码规范本身不直接降低维护成本，真正起作用的是规范背后强制执行的组织逻辑和约束——比如变量必须前置、@import顺序不可乱、嵌套不能超过三层。这些不是“建议”，而是编译期硬性规则，违反就会导致样式失效或难以调试。
变量必须在使用前定义且全局唯一
Less 变量是编译期静态替换，没有运行时作用域概念。一旦在后续文件或嵌套块中重声明同名变量，前面的定义就彻底失效。
-
@primary-color在_variables.less中定义后，所有引用它的文件（如_buttons.less）必须在@import "_variables.less"之后才被引入 - 禁止在嵌套规则里写
.card { @primary-color: red; color: @primary-color; }—— 这会创建局部变量，外部无法感知，也违背“一处修改全局生效”的初衷 - 调试时可在末尾加
.debug { color: @primary-color; }，编译后看输出值是否符合预期，快速定位是否被覆盖或未加载
@import 顺序错乱是变量失效最常见原因
Less 不支持“按需加载”或“依赖解析”，@import 是线性拼接，顺序即依赖关系。把 _mixins.less 放在 _variables.less 前面，里面所有用到 @base-padding 的混入都会编译失败或静默忽略。
- 所有
@import必须统一用双引号或单引号，且.less后缀不可省略：@import "variables.less";✅，@import 'mixins';❌ - 推荐固定顺序：变量 → 混入 → 基础样式 → 组件 → 页面级样式，这样后续文件能安全依赖前面的定义
- 跨项目复用时，避免在子模块里
@import全局变量，应由主入口统一控制加载链
嵌套层级超过 3 层会显著抬高维护门槛
嵌套本身不慢，但生成的选择器权重和 CSS 体积会指数增长。.layout .header .nav .item:hover 这类选择器不仅难覆盖，还让浏览器匹配更耗时，而且一旦结构微调，整段嵌套就得重写。
立即学习“前端免费学习笔记（深入）”；
- 超过 3 层嵌套时，优先拆出语义化 class，例如把
.card .content .title改为.card-title - 用
&避免重复书写父选择器，但别堆叠：.list { & > li { & > a { } } }已越界，应止步于.list > li > a - 真正需要语义嵌套的场景才保留，比如
.modal { .modal-header {} .modal-body {} }—— 这类结构稳定、复用集中，且不会跨组件泄漏
Mixins 带参数不等于可随意复用
每个带参数的 mixin 调用都会生成一份独立 CSS，不是运行时函数调用。调用 20 次 .flex-center(@dir)，就生成 20 份 display: flex 块，哪怕其中 18 次参数相同。
- 高频原子样式（如
.text-truncate、.sr-only）更适合定义为独立 class，通过@import引入，而非每次调用 mixin - 含条件判断的 mixin（如
.btn-style() when (@size = large)）慎用，Less 编译器会把所有分支都展开，不作裁剪 - 纯样式复用（如
border-radius、transition）适合无参 mixin；涉及尺寸/颜色计算的，优先用变量 + 运算，而非动态 mixin
最难被意识到的一点：规范的价值不在“写得整齐”，而在于它把隐性依赖显性化。比如 @import 顺序、变量前置、嵌套限制，每一条都在逼你提前思考模块边界和依赖流向——这才是降低维护成本的核心动作。
