语义化变量命名应表达用途而非色值，如@primary-color、@text-emphasis；模块按功能切片并设私有边界；Mixin用于动态逻辑，:extend()用于静态复用；配置需对齐paths与缓存。
Less变量命名怎么才算语义化，而不是堆砌颜色值？
变量名不是@blue-200或@dark-gray这种“描述色值”的写法，而是表达用途：比如@primary-color对应品牌主色，@text-emphasis对应强调文字，@border-divider对应分隔线。一旦设计系统调整主色，改一个变量就全局生效；如果写成@blue-500，换色时你得翻遍所有文件找哪些地方用了它，还容易漏。
- 避免用
@header-bg这类带具体组件名的变量——Header背景可能在其他地方复用，应拆成@surface-level-1（表面层级）+@primary-color组合 - 颜色变量只定义“角色”，不绑定具体实现：
@primary-color: #007bff;，而不是@primary-color: darken(#007bff, 10%);——后者会让调用方失去控制权 - 字体、间距、圆角等同理：
@font-size-base、@spacing-md、@radius-sm，而非@font-14px或@radius-4px
如何用Less模块拆分避免@import地狱？
把所有样式塞进一个main.less再层层@import，最后编译慢、定位难、协作易冲突。正确做法是按功能域切片，且明确入口与私有边界。
- 每个模块只暴露必要接口：比如
buttons.less只输出.btn和.btn--primary，内部的@btn-padding-x等变量用@_btn-padding-x（以下划线开头）标记为私有，不被外部依赖 - 入口文件（如
index.less）只做聚合，不写样式逻辑：@import "variables"; @import "mixins"; @import "components/buttons"; - 禁止跨模块直接引用私有变量：不能在
forms.less里读buttons.less里的@_btn-height，要用@input-height这类统一定义的变量对齐
Mixin和Extend哪个更适合抽象重复样式？
看是否需要传参和运行时计算。Mixin是函数，适合动态生成；Extend是静态继承，适合纯结构复用。混用或误用会导致CSS体积膨胀或选择器失控。
- 用Mixin处理可变逻辑：比如
.text-truncate(@width: 100%)生成max-width和省略号规则；.flex-center()封装居中flex声明 - 用
:extend()替代重复类名：比如.icon { display: inline-block; vertical-align: middle; } .user-icon:extend(.icon) {}，编译后共用同一套CSS声明，不复制属性 - 别用
:extend()跨语义层级：不能让.card-header:extend(.text-h4)——标题样式不该继承字体大小定义，这是职责错位 - 注意Mixin嵌套过深会拖慢编译，尤其带循环的；简单复用优先用
:extend()，复杂逻辑才上Mixin
Webpack或Vite里Less配置容易忽略的兼容性坑
本地开发跑得通，上线后样式错乱，大概率是Less解析上下文或路径别名没对齐。
-
paths配置必须包含node_modules：否则@import "~bootstrap/less/mixins"会失败，Vite需配less.additionalData加全局变量，Webpack需less-loader的paths选项 - 慎用
javascriptEnabled: true（Less 4.x默认关闭）：开启后支持@color: `document.body.style.color`这类JS表达式，但破坏CSS可预测性，CI环境可能报错 - 变量覆盖顺序很关键：项目
variables.less必须在bootstrap.less之前@import，否则Bootstrap内置变量无法被重写 - 修改变量后记得清缓存：Vite的
.vite/deps、Webpack的node_modules/.cache都可能缓存旧编译结果，导致改了变量却没生效
实际维护中，最难的不是写Less语法，而是守住模块边界和变量语义——改一个@spacing-lg，得清楚它影响多少组件、是否所有容器都遵循同一套间距阶梯。这点靠文档没用，靠的是每次@import和@define时多想半秒。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
