less变量覆盖失败的根本原因是编译链断裂：变量必须在样式引用前定义并注入，否则首次引用时已固化为默认值；正确做法是单点定义、前置导入、禁止嵌套重赋值。
Less 里没有“变量重命名机制”，所谓“覆盖旧版CSS样式”本质是控制变量定义顺序和作用域，让新值在编译时替换旧值——不是重命名，是线性覆盖。
为什么@primary-color改了但按钮颜色没变？
常见错误是以为改一个变量就能全局生效，其实 Less 变量在首次被引用时就已展开为具体值。比如 .btn { color: @primary-color; } 这行代码在编译时直接替换成 .btn { color: #007bff; }，后续再改 @primary-color 对它毫无影响。
- 检查变量是否在组件样式之前就被定义并使用：如果
button.less里写了color: @primary-color;，而variables.less在它之后才@import，那按钮用的还是默认值（或未定义导致编译失败） - 确认没有在多个地方重复声明同名变量：后声明者生效，但 IDE 和开发者工具不会报冲突警告
- 避免在嵌套块中重新赋值：
.card { @primary-color: red; .btn { color: @primary-color; } }会污染全局@primary-color，不只是局部生效
如何安全地“覆盖”旧变量而不引发意外替换？
核心是收口 + 前置 + 隔离。不要依赖“重命名”或“作用域遮蔽”，Less 没有这些概念。
- 所有公共变量统一定义在单个
variables.less文件中，禁止在组件文件里写@primary-color: ...; - 入口文件（如
index.less）必须按顺序@import 'variables.less';→@import 'components/button.less';→@import 'themes/dark.less'; - 主题覆盖文件（如
dark.less）只写无!default的直接赋值：@primary-color: #e74c3c;，不写@primary-color: #e74c3c !default; - 给变量加命名空间前缀，比如
@theme-primary-color、@layout-spacing-base，避免和第三方库（如 Ant Design 的@primary-color）撞名
怎样验证变量是否真的被覆盖成功？
别只看最终 CSS 文件里有没有新颜色，要确认变量值在编译期就被正确注入到每一条样式规则中。
- 在
button.less开头加一行// @debug: @primary-color = @{primary-color}，然后用lessc --verbose编译，看输出里是否显示你预期的值 - 用
lessc --lint检查重复定义（Less 4.0+ 支持），它会提示某变量在多个文件中被声明 - 打开浏览器 DevTools 的 Styles 面板，找到对应元素，右键“Reveal in Sources”，跳转到编译后的 CSS 行，反向定位原始 Less 行号（需开启 source map）
- 禁用所有主题文件，只保留
variables.less，确认基础样式是否正常；再逐个启用主题，观察变化是否符合预期
最容易被忽略的是：变量覆盖只发生在编译开始前的变量解析阶段，一旦某条样式规则里出现过 @xxx，它的值就锁死了。所谓“动态覆盖”只是换一套变量重新编译，不是运行时切换。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
