less规范核心在于变量分层、@import可控、mixin参数化及命名空间隔离。变量须按语义定义，避免硬编码；@import统一用(reference)模式并经index.less入口；mixin需带默认参数且禁嵌套；私有变量加下划线，跨模块复用走统一池；命名空间防污染，伪类嵌套需谨慎。
Less本身不强制规范，但放任变量和@import随意使用，半年后就没人敢动样式了。关键不是“用不用Less”，而是怎么用才不给自己挖坑。
变量必须按语义分层定义，别堆颜色值
看到@blue-500或@gray-3这种变量名，基本可以判定后续维护会出问题。颜色、间距、圆角这些值得绑定用途，而不是色值本身。
-
@primary-color对应品牌主色，不是#007bff的别名；改主题时只动这一处，所有.btn、.link自动响应 - 组件内局部值（比如
.card的阴影偏移）用lighten()、fade()动态算，不抽成变量——否则改一个@shadow-depth，可能连表单输入框的边框都变淡了 - 第三方CSS（如
ant-design）不抽变量，用:host ::ng-deep或data-theme隔离，避免污染设计系统边界
Mixin要带参、有契约，别写无参空壳
像.reset-list { list-style: none; margin: 0; padding: 0; }这种无参Mixin，不如直接写class="reset-list"。它没抽象逻辑，只有复制粘贴价值。
- 参数化Mixin必须显式声明默认值：
.border-radius(@r: @radius-sm)，漏传不会报错，但.border-radius()会编译失败 - 内部禁止硬编码值，全部引用变量：
background-color: @color-bg;，而不是background-color: #f8f9fa; - 别在Mixin里嵌套调用另一个Mixin再用
@gap——如果@gap在别处被重定义，结果不可控
@import顺序和模式决定编译是否可靠
Less不是按文件路径排序，而是线性展开@import语句。你以为variables.less在最前就稳了？不一定——某个组件文件里@import "variables"，会把它插进中间，覆盖你原本的定义。
- 所有基础文件（
variables.less、mixins.less）统一用@import (reference)引入，不输出CSS，只提供上下文 - 每个模块目录下设
index.less，只做两件事：声明本模块依赖、暴露对外样式入口；components/button/index.less里只写@import "variables"; @import "mixins"; @import "button"; - 业务页文件（如
pages/dashboard.less）永远只@import "../index"，不直引../../base/variables——路径一改，全挂
命名空间和私有变量得有明确边界
变量名冲突不是偶然，是结构松散的必然结果。没有边界，@btn-padding和@input-padding早晚撞车。
- 模块内私有变量加下划线前缀：
@_btn-height，约定不被外部引用；跨模块复用一律走统一变量池（如@spacing-md） - 命名空间用
#ui-kit这类ID封装，调用时写#ui-kit > .button()，避免.button()全局污染 - 禁止在伪类里嵌套
&再套命名空间，比如.btn:hover { &.active { ... } }配合命名空间容易生成.myapp-btn.myapp-btn:hover这种冗余选择器
最难的不是写对语法，而是让所有人遵守同一套导入链和变量层级。一旦有人绕过index.less直引深层文件，或者在组件里重新定义@primary-color，整个体系就开始松动。规范不是文档，是构建流程里的硬约束。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
