Less 中变量和 mixins 过度使用会拖慢编译并增大输出体积，因其静态替换机制导致重复 CSS、选择器权重飙升及调试困难，需谨慎控制嵌套层级、导入顺序与动态运算。
变量和 mixins 用多了反而拖慢编译和输出体积
Less 编译是静态替换过程，@import 多个文件、大量调用带参数的 .button-style() 这类 mixins，会直接导致 CSS 输出重复——比如一个按钮混入被 12 个组件引用，最终就生成 12 份相同的 border-radius、padding 块，而不是合并成一条规则。
- 高频原子样式（如
.text-truncate、.visually-hidden）适合抽成独立 class +@import，而非每次调用 mixins - 带条件逻辑的 mixins（如
.flex-center() when (@direction = row)）慎用，编译器无法做运行时判断，只会把所有分支都展开 - 用
lessc --strict-math=on避免除法写成68 / 37.5rem这种不加括号的表达式，否则编译可能静默失败或产出错误值
嵌套超过 3 层就该警惕 specificity 和体积问题
嵌套本身不慢，但生成的选择器权重会指数级上升：.page .section .card .header .title 不仅难覆盖，还让浏览器匹配更耗时；同时每层嵌套都会在输出 CSS 中复制父选择器前缀，体积翻倍风险很高。
- 真正需要语义嵌套的场景才用：比如
.modal { .modal-header {} .modal-body {} } - 用
&替代重复书写父选择器，但别堆叠：.btn { &:hover { } &.primary { } }安全；.list { & > li { & > a { } } }已越界 - 超过 3 层时，优先拆出独立 class，或改用
:extend(.base-style)合并选择器（注意：:extend跨文件不可见，且不能 extend 变量或 mixins）
导入顺序错乱会让变量“看似定义了却没生效”
Less 没有运行时作用域，变量生效只取决于编译时顺序。常见现象是改了 @primary-color，但按钮颜色不变——往往是因为 @import "_variables.less" 写在了 @import "_buttons.less" 后面，或者被局部嵌套覆盖。
- 所有变量必须放在最顶层
_variables.less文件中，并确保它@import在其他任何文件之前 - 避免在嵌套块里重定义同名变量：
.card { @primary-color: #f00; color: @primary-color; }这里的@primary-color是局部作用域，外部看不到 - 调试技巧：在全局末尾加
.debug-var { color: @primary-color; }，编译后看实际输出值是否符合预期
运算和函数不是万能的，过度动态反而增加维护成本
用 lighten(@primary-color, 10%) 生成悬停色看起来很智能，但如果设计稿要求“所有 hover 色固定为 #2980b9”，这种计算就变成隐式依赖，后续换主题时反而要挨个查函数调用点。
立即学习“前端免费学习笔记（深入）”；
- 颜色函数适合生成衍生色（如禁用态、背景浮层），但主色、品牌色建议直接定义变量，不参与运算
- 响应式断点用
@media (min-width: @screen-md)没问题，但别写@media (min-width: (@screen-lg - 1px))——可读性差，且 Less 不支持跨单位运算（100vw - 2rem会报错） - 数学运算优先用于布局计算（如
width: (100% / 3) - 20px;），别用来模拟 JS 行为（如根据屏幕宽自动切列数）
真正卡住性能的不是 Less 语法本身，而是把「写起来爽」当成「跑起来快」——变量和 mixins 的复用价值，永远要拿最终 CSS 体积、选择器权重、调试成本来兑付。
