在谈论CSS变量与Sass变量的选择时，最核心的一条分界线是：一个能在运行时被修改，一个则不能。问题的核心，不在于哪个更好用，而在于有没有这个能力。 这么说可能会有点抽象。我们来拆开看：CSS变量本质上是浏览器原生支持的自定义属性，它可以在页面运行的任何阶段，通过JavaScript被动态读写并触发
在谈论CSS变量与Sass变量的选择时，最核心的一条分界线是：一个能在运行时被修改，一个则不能。问题的核心，不在于哪个更好用，而在于有没有这个能力。
这么说可能会有点抽象。我们来拆开看：CSS变量本质上是浏览器原生支持的自定义属性，它可以在页面运行的任何阶段，通过JavaScript被动态读写并触发样式重绘。而Sass变量，只不过是一个编译期的占位符，当.scss文件被编译成最终的.css文件时，`$color`这个符号就已经彻底消失了，变成了一串死板的静态数值。
**简单粗暴地说，Sass变量是写进墙里的固定装饰，CSS变量则是可以随时调节的开关。这是根本差异，不是哪个好用，而是能不能做。**
### var(--color) 能被 JS 动态修改，$color 不能
注意看差别：
- 如果你想修改 `--primary-color` 的值，只需要一行JavaScript代码：`document.documentElement.style.setProperty('--primary-color', '#ff6b6b')`。就这么简单，所有引用了 `var(--primary-color)` 的元素，会立刻、自动地触发重绘。
- 但你没法用同样的方式去动 `$primary-color`。因为它已经完成了它的使命——在编译器里替换成了具体的颜色值 `#4285f4`。JavaScript拿不到，改不了，也触发不了任何样式更新。
- 不少人在Vue或React组件里写过 `style="--color: {{ dynamicColor }}"`，却用Sass变量去定义主题色。结果呢？颜色死活不响应状态变化。错误根源就在这里：因为JS改的是CSS变量的值，但UI渲染时读的还是那个已经硬编码了的Sass变量数值。
### 主题切换，这才是正解
用户点一下“深色模式”，页面必须能在毫秒级内响应。这时候需要的，是样式值能被实时注入到DOM中，而不是去网络那头重新请求一个打包好的 `dark.css` 文件。
- 用CSS变量实现主题切换，一劳永逸：只维护一套CSS文件。页面里只需要通过JavaScript修改 `:root` 下的 `--bg`、`--text` 等几个变量值就能切换主题色。没有网络请求、没有闪屏、不需要重新构建。这才是现代主题切换应该有的样子。
- Sass走的老路是：预先编译出 `light.css` 和 `dark.css` 两套文件，然后用JavaScript去切换 `
` 标签。这样做的代价是：加载延迟、缓存问题、以及最重要的一点——你无法在切换主题时做平滑的渐变过渡（`transition: background` 对硬编码的静态值是无效的）。
- 从性能角度看：CSS变量方案只更新了少量属性，内存占用极低。而Sass的多主题方案凭空增加了bundle体积，每次切换样式表都可能导致页面重新解析样式，体验上差距明显。
### 作用域与继承，决定可维护性边界
CSS变量的作用域，遵循CSS自身的层叠规则。这天然适合组件化开发。你在一个 `.card` 元素上给 `--spacing-md` 设成 `16px`，它的所有子元素会直接继承这个变量值，无需额外声明。而Sass里，如果在一个mixin中用了 `$spacing-md`，你必须显式地传参，或者依赖一个遍布全局的变量定义——很容易失控。
看看那些主流组件库是怎么做的。Element Plus、Ant Design普遍都开始暴露CSS变量作为定制入口，比如 `--el-color-primary`。使用者只需覆盖这个变量，就能瞬间实现换肤。换成Sass版本，你必须找到整个 `_variables.scss` 文件重写一遍，还要重新参与构建流程。
这里有一个特别容易踩的坑：在Vue单文件组件的 `
