Less优势在于可维护性、复用性和组织效率，而非运行速度；变量编译期替换避免重复与污染，嵌套提升结构一致性但需防选择器膨胀，Mixin封装逻辑零体积开销，但配置不当易致构建失控。
Less 的优势不在“运行更快”或“功能更强”，而在于它能帮你把样式写得更稳、改得更准、协作时少扯皮——前提是项目规模超过 300 行 CSS，且多人维护。
变量是编译期替换，不是运行时计算
原生 var(--color) 依赖 CSS 作用域链和加载顺序，:root 定义晚了、JS 动态注入时机不对、SSR 渲染时未注入，都会导致 fallback 失效。Less 的 @primary-color 在编译阶段就替换成具体值，比如 color: @primary-color; 直接输出 color: #1890ff;，不依赖浏览器解析逻辑。
- 变量跨
@import自动合并，适合拆成variables.less+theme-dark.less - 重复定义不报错，后导入的
@spacing会静默覆盖前一个——大型项目里常因 import 顺序错乱引发颜色/间距漂移 - 不支持 JS 动态读取或修改，想换肤必须重新编译，不适合 runtime 主题切换场景
嵌套规则让结构可读，但选择器膨胀风险真实存在
写 .card { &__header { color: @text-primary; } } 看起来贴近 DOM 结构，但编译后生成的是 .card__header，和 BEM 规范一致；而误用 .card { .header { ... } }（没加 &）会产出 .card .header，层级过深易触发性能警告，尤其在移动端 WebKit 下影响渲染帧率。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 媒体查询嵌套是真省事：
@media (max-width: 768px) { padding: @spacing * 2; }不用重复写父选择器 -
&:hover、&::before这类伪类必须带&，漏掉就变成全局匹配，容易污染其他组件 - 嵌套超过 4 层后，CSS 文件体积增长明显，Webpack 构建时
less-loader编译耗时上升约 15%～20%
Mixin 封装零体积开销，但参数默认值容易被忽略
.border-radius(@radius: 4px) 定义后，.button { .border-radius(); } 编译结果就是 border-radius: 4px;，没有额外 class 或 JS 运行时成本。但问题出在调用侧：如果传参时漏掉单位，比如 .border-radius(6)，Less 默认当像素处理，而 .border-radius(0.5em) 才真正生效——这种隐式单位转换在团队协作中极易引发视觉误差。
立即学习“前端免费学习笔记（深入）”；
- Mixin 不支持条件分支（如
if），复杂逻辑得靠多个变体或拆成 JS 工具函数 - 命名空间混用时（
.utils.rounded()），需确保@import路径正确，否则编译报错undefined mixin - 带参数的 Mixin 在
math=strict模式下对运算精度更敏感，@spacing * 1.5可能产出12.000000000000002px
真正决定要不要用 Less 的，不是它能多炫技，而是你团队是否愿意为变量命名规范、@import 顺序、嵌套深度设下硬约束——这些地方一旦松动，编译产物就可能和预期偏差几像素，而浏览器开发者工具里根本看不出是哪一行 Less 写错了。
