Less变量需加@ui-前缀避免与CSS自定义属性冲突；主题切换依赖CSS变量+媒体查询，非Less条件；import顺序决定变量覆盖，项目变量须置顶；!default仅在未定义时生效，覆盖需主动重赋值。
Less变量命名怎么避免和CSS原生变量冲突
Less编译时变量是纯预处理替换，和CSS运行时的--color-primary完全不打架——但人会搞混。常见错误是写@primary-color: #007bff;，又在CSS里用color: var(--primary-color);，结果样式失效，因为Less根本不会把@primary-color转成--primary-color。
- 统一前缀：所有Less变量加
@ui-前缀，比如@ui-color-primary、@ui-spacing-md - CSS自定义属性单独维护：用
:root块显式声明--ui-color-primary，值可从Less变量导入（需配合~"..."或插件） - 别指望Less自动同步：
@ui-border-radius改了，--ui-border-radius不会自动更新，必须手动同步或用构建脚本生成
如何让一套Less变量适配深色/浅色主题切换
Less本身不支持运行时条件分支，所谓“主题切换”其实是编译时生成多套CSS，或靠CSS变量兜底。最容易踩的坑是把主题逻辑全塞进Less里，结果换主题要重新编译、无法动态切。
- 基础色板用
@ui-color-bg-light、@ui-color-bg-dark等成对定义，不直接写background: @ui-color-bg; - 组件内优先用CSS变量：比如
background: var(--ui-color-bg, @ui-color-bg-light);，保证降级可用 - 深色模式检测交给媒体查询：
@media (prefers-color-scheme: dark) { :root { --ui-color-bg: @ui-color-bg-dark; } }，而不是用Less的.if()模拟 - 避免在
.mixin里硬编码主题判断，Mixin应只做样式复用，主题逻辑外移
Less import顺序影响变量覆盖的实际表现
Less变量是“最后定义生效”，但import不是简单拼接，而是按引入顺序逐层展开。很多人以为把variables.less放在最前就万事大吉，结果被第三方UI库的@button-padding覆盖了自己定义。
- 必须把项目级变量文件放在所有
import的最顶部，包括node_modules里的库 - 用
@import (reference)引入第三方Less时，它内部的变量不会污染当前作用域——但如果你用普通@import，它的@button-height就会覆盖你自己的 - 检查实际编译输出：搜索CSS里某条规则的来源，反推是哪个
@import链注入的变量值 - Webpack或Vite中，Less loader的
additionalData配置比@import更可控，适合注入全局变量
为什么!default不能解决所有变量覆盖问题
@color-primary: #007bff !default;看起来很美，但一旦上游库也用了!default，谁先被读取谁赢——而读取顺序取决于@import位置，不是声明顺序。
立即学习“前端免费学习笔记（深入）”；
-
!default只在变量**尚未定义**时生效；如果前面已有@color-primary: red;，后面@color-primary: blue !default;直接被忽略 - 第三方库若没加
!default，你就没法安全覆盖它，只能靠调整@import顺序或重命名变量 - 真正需要覆盖时，不如主动“重赋值”：在项目变量文件末尾写
@color-primary: @ui-color-primary;，明确接管 - CI流程里建议加校验：用正则扫描输出CSS，确认关键变量值符合预期，而不是依赖
!default的模糊语义
变量系统真正的复杂点不在语法，而在团队协作时对“谁定义、谁覆盖、谁负责同步”的隐性约定。没有!default能绕过这个。
