Less变量需带语义前缀如@color-primary，Mixin须设参数约束与默认值，嵌套限3层内并显式写父子选择器，import顺序固定为variables→mixins→reset→components→pages。
Less变量命名必须带语义前缀
团队协作中，@primary-color 这种裸名变量极易被覆盖或误用。不加前缀的变量在多个模块引入时，@blue 和 @blue 看似一样，实则可能来自不同文件、值不同，最终编译结果不可控。
建议统一使用作用域+类型双前缀，比如：@color-primary、@spacing-sm、@zindex-modal。避免 @main-blue 这类模糊命名，它既没说明用途（是背景？边框？文字？），也没说明层级（是主题色还是临时色？）。
- 所有颜色变量以
@color-开头，禁止出现@blue、@red-500 - 间距统一用
@spacing-，如@spacing-xs、@spacing-lg，不写@margin-base - 字体大小用
@font-size-，如@font-size-h2，而非@h2 - 变量定义只放在
variables.less，其他文件禁止用@import引入局部变量文件
Mixin必须有明确输入约束和默认回退
写一个 .flex-center() 却不声明参数，默认值又写死 justify-content: center，结果某人调用时传了 .flex-center(flex-start) 却没生效——因为没定义参数接收逻辑，Less 直接静默忽略。
Mixin 不是函数，没有运行时类型检查，参数错位、多传、少传都不会报错，只会在 CSS 输出里悄悄消失或错配。
立即学习“前端免费学习笔记（深入）”；
- 必填参数用
@param注释说明，例如// @param {string} @justify: justify-content 值 - 所有参数必须设默认值，哪怕只是
~""或initial，防止未传参时编译失败 - 避免无参 mixin（如
.clearfix()），改用带条件判断的版本：.clearfix() when (isstring(@_)) { ... }，降低误用概率 - 慎用
...可变参数，它会让调用签名模糊，团队成员无法快速判断该 mixin 支持哪些组合
嵌套层级超过 3 层必须拆出独立选择器
.card { .header { .title { .icon { ... } } } } 编译后生成 .card .header .title .icon，看似结构清晰，实则耦合极重：只要 DOM 少一层，样式就失效；想复用 .icon 样式？得连着四层父选择器一起搬。
更麻烦的是，这种嵌套会掩盖真实的选择器权重问题。调试时看到元素没生效，翻半天才发现是 .card .header .title .icon 权重太高，压过了组件库里的 .btn-icon。
- 嵌套仅用于修饰关系明确的场景，如伪类
&:hover、状态类&.is-active - 父子结构一律显式写出，如
.card-header-title-icon或.card .title-icon - 用
&时禁止跨级，& > ul > li a是允许的，& ul li a就该警惕——它等价于宽松后代选择器，易污染 - 构建工具可配
less-plugin-glob配合 lint 规则，自动拦截 4 层以上嵌套
import顺序决定变量覆盖行为，必须固定规则
Less 没有模块作用域，@import 是线性展开的。如果 theme-dark.less 在 variables.less 之后 import，它重定义的 @color-bg 才有效；反过来，就被覆盖成白底了——而错误往往只在深色模式下才暴露。
更隐蔽的是，某些团队把第三方 UI 库的 Less 文件也 @import 进来，结果它的 @border-radius-base 覆盖了你自己的，圆角突然变大，却查不到源头。
- 强制按顺序 import：
variables→mixins→reset→components→pages - 所有第三方库的 Less 必须单独建
vendor/目录，并在最顶部 import，且加注释说明为何要提前（如“需覆盖其变量”） - 禁用
@import (multiple)，它会绕过顺序控制，导致同一变量被多次定义却不报错 - 用
lessc --verbose编译时观察变量解析路径，确认最终生效的是哪个文件里的定义
变量前缀、Mixin 参数、嵌套深度、import 顺序——这四个点看着琐碎，但每个都卡在编译期，一旦出错，不会报错，只会静默产出错误 CSS。最容易被忽略的是 import 顺序：它不写在代码里，却决定了整个样式系统的可信边界。
