Sass变量无作用域保护，后声明同名全局变量会覆盖前值；!default仅在首次赋值时生效，需通过导入顺序、命名空间和@use控制覆盖。
为什么$color-primary在组件里突然变蓝了
不是浏览器缓存或 DevTools 显示错误，而是 Sass 在编译时把某个后定义的同名变量直接覆盖了前值——Sass 变量没有“作用域保护”，只要同名、同层级（全局），后声明就赢。典型场景：你写了 $color-primary: #007bff，但 UI 库的 _variables.scss 也在同一作用域下执行了 $color-primary: #1890ff，且它的 @import 出现在你之后。
- 全局变量一旦被赋值，后续同名
$var: value !default完全不生效 -
@use模块内的变量默认私有，但若用as *全量导入，仍会触发全局覆盖 - Vue 单文件组件的
<style lang="scss"></style>里定义变量，会被视为独立作用域，但若多个组件都@import同一文件，就又回到全局污染 - Webpack 的
sass-resources-loader会把变量注入每个 SCSS 文件顶部，相当于所有文件开头都执行了一遍赋值，极易造成重复定义
怎么确认是哪个文件偷偷改了你的变量
别猜，直接搜。打开整个项目（含 node_modules），全局搜索 $color-primary:（注意冒号），重点看三处：
- UI 库路径下，如
node_modules/ant-design-vue/scss/_variables.scss - Vite 或 Webpack 配置里的
additionalData字段，它可能提前注入了变量 - 你自己项目中是否存在多个
@import链，比如a.scss→b.scss→c.scss，而c.scss里又重新赋值
更准的方法：在疑似被覆盖的变量文件末尾加一行 @debug $color-primary;，运行编译，终端输出的值就是最终生效值。
真正安全的覆盖方式：顺序 + 命名空间 + @use
!default 不是保险丝，是抢跑器——它只在变量第一次出现时起效。要让覆盖可靠，必须控制“第一次”出现在哪。
立即学习“前端免费学习笔记（深入）”；
- 把自定义变量抽成单独文件，比如
src/styles/override.scss，只放带!default的声明 - 在所有其他 SCSS 文件之前 import 它：
@import "src/styles/override";（注意不是@use） - 对第三方库改用
@use "ant-design-vue/scss/index" as antd;，然后通过antd.$primary-color访问，避免命名冲突 - 禁用
as *：@use "vars" as *;是危险操作，应改为@use "vars" as theme;，再用theme.$primary
容易被忽略的“覆盖假象”
有时候你以为变量被覆盖了，其实是 CSS 层级没赢。比如你在 .btn 里写 color: $color-primary;，但页面上按钮还是灰色——这很可能是因为某条高权重规则（如 .btn.is-disabled { color: #ccc !important; }）压过了你生成的 color: #007bff;。
- Sass 变量编译后变成静态值，它不参与 CSS 优先级计算；覆盖失效往往发生在 CSS 输出层，而非 Sass 编译层
- 检查 DevTools 的 Styles 面板，看
color是否被划掉；如果被划掉，点文件名确认是哪条规则在前 - 不要在
:root里用--primary: $primary;——这行根本不会被编译，必须写成:root { --primary: #{$primary}; }
最麻烦的情况是变量值本身依赖其他变量，比如 $primary-dark: darken($color-primary, 10%) !default;，一旦 $color-primary 未定义，darken() 直接报错，!default 根本没机会执行。
