Less优势在于可维护性、复用性和组织效率，而非运行速度；变量编译期替换避免重复与污染，嵌套提升结构一致性但需防选择器膨胀，Mixin封装逻辑零体积开销，但配置不当（如math模式、import路径）易致构建失控。
Less 在处理大批量 CSS 样式时，并不天然“更快”或“更优”，它的优势只在**可维护性、复用性和组织效率**上成立；一旦脱离人工协作场景（比如单人写 500 行纯视觉样式），原生 CSS 反而更直接、无编译开销、无隐式行为风险。
变量复用避免重复声明和全局污染
批量样式最常见问题是颜色、间距、断点等值四处散落。原生 var() 虽然也能做，但必须保证作用域链正确、:root 提前定义、JS 动态注入不破坏 SSR —— 实际项目里常因顺序错乱导致 fallback 失效。
Less 变量是编译期替换，无运行时依赖：
-
@spacing-xs: 4px;写一次，全项目margin: @spacing-xs;直接展开为margin: 4px; - 修改
@spacing-xs后所有引用自动更新，无需 grep + 替换 + 验证是否漏改 - 变量可跨文件
@import，天然支持主题包拆分（如theme-dark.less覆盖基础变量）
注意：变量名冲突不会报错，@primary-color 在两个 @import 文件里重复定义，后导入的会覆盖前一个——这在大型 H5 项目中极易引发暗坑。
立即学习“前端免费学习笔记（深入）”；
嵌套规则提升结构一致性，但必须警惕选择器膨胀
原生 CSS 没有嵌套语法，靠人工维持层级命名（如 .card__header），容易松散失序；Less 允许写：
.card {
padding: 12px;
&__header { font-size: 16px; }
&__body { line-height: 1.5; }
}编译后生成标准类名，结构清晰。但问题在于：
- 嵌套过深（>4 层）会导致选择器冗长，如
.page .layout .main .card .card__header，影响 specificity 和性能 -
&引用父选择器时，若父名含 BEM 或动态 class，可能意外拼出非法选择器（如.btn--large&:hover编译为.btn--large.btn--large:hover） - 媒体查询不能靠嵌套“省事”：
.btn { @media (min-width: 768px) { ... } }会生成.btn @media，浏览器忽略——必须提级写
Mixins 封装高频样式逻辑，但别滥用参数化
移动端大量按钮、表单、卡片需要统一圆角、阴影、禁用态。用 Mixin 封装比复制粘贴安全得多：
.btn-base(@radius: 4px) {
border-radius: @radius;
transition: all 0.2s;
}
.btn-primary { .btn-base(6px); }关键点：
- Mixin 不生成独立 CSS，只展开内容，体积零额外开销
- 参数支持默认值和类型检查（
isnumber(@radius)），但需手动加 guard，否则单位混用（2 * 16pxvs16px * 2）结果不同 - 避免写“万能 mixin”：比如
.flex-center(@dir, @wrap, @justify)，参数一多，调用时反而比写原生还费劲
编译产物可控，但构建链路必须卡死 math 和 paths
Less 的真正优势不在语法，而在输出确定性。但这个确定性极容易被默认配置破坏：
-
lessc在 Node.js v14+ 默认--math=always，@gap: 8px * 1.5→12px，但@gap: 1.5 * 8px→12（丢单位！）→ 布局塌陷 -
@import "mixins/border"默认从当前文件目录解析，不是项目根目录；多页 H5 中，/page/a.less和/page/b.less导入同名 mixin，实际加载的是两份不同文件 - 不加
--strict-math=on和--lint，语法错误可能静默忽略，上线后才发现某块样式没编译进去
批量样式越庞大，这些配置越不能靠“默认”。哪怕只改一行变量，也得确认它是否真的进入了最终 CSS —— 最稳妥的方式是打开 sourcemap 并 inspect 编译后的 CSS，而不是相信控制台没报错。
