CSS变量可被JavaScript动态读写并触发实时重绘，Sass变量仅在编译期生效、运行时不可修改——本质差异在于是否支持运行时干预。
CSS变量在现代框架中能直接被JavaScript读写并触发样式重绘，Sass变量编译后就固化成静态值，无法在运行时干预——这是根本差异，不是“哪个更好用”，而是“能不能做”。
var(--color) 能被 JS 动态修改，$color 不能
CSS变量本质是自定义属性，浏览器原生支持其运行时更新；Sass变量只是编译期占位符，最终输出的CSS里根本不存在 $color 这个符号。
- 修改
--primary-color：用document.documentElement.style.setProperty('--primary-color', '#ff6b6b')即刻生效，所有引用var(--primary-color)的元素自动重绘 - 试图修改
$primary-color：编译完成后它已变成硬编码的#4285f4，JS 拿不到、改不了、也触发不了任何样式更新 - 常见错误现象：在Vue/React组件里写了
style="--color: {{ dynamicColor }}"，但用了Sass变量定义主题色——结果颜色完全不响应状态变化
主题切换必须依赖 CSS 变量，Sass 只能靠多套编译产物
用户点击“深色模式”时，页面需要毫秒级响应。这要求样式值能实时注入DOM，而不是重新请求一个打包好的 dark.css 文件。
- CSS变量方案：只维护一套CSS，通过切换
:root下的--bg、--text等变量值实现主题切换，无网络请求、无FOUC、无构建介入 - Sass方案：需预编译出
light.css和dark.css，再用JS切换<link>标签，存在加载延迟、缓存问题、以及无法做渐变过渡（transition: background对静态值无效） - 性能影响：CSS变量方案内存占用低，仅更新少量属性；Sass多主题方案增加bundle体积，且每次切换都可能引发样式表重解析
作用域与继承机制决定可维护性边界
CSS变量按CSS层叠规则生效，天然适配组件化开发；Sass变量的作用域由文件导入顺序和嵌套层级决定，容易失控。
立即学习“前端免费学习笔记（深入）”；
-
--spacing-md在某个.card元素上设为16px，其子元素直接继承，无需额外声明；而Sass中若在mixin里用$spacing-md，必须显式传参或依赖全局定义 - 组件库（如Element Plus、Ant Design）普遍暴露CSS变量作为定制入口（
--el-color-primary），使用者可通过覆盖变量快速换肤；Sass版本则必须重写整个_variables.scss并参与构建流程 - 容易踩的坑：在Vue单文件组件的
<style scoped>中定义:root { --color: red }——该变量不会生效，因为:root是全局根节点，scoped会加属性选择器导致匹配失败；应改用:host（Web Components）或移至非scoped块
兼容性不是借口，IE11 已退出主流支持场景
2026年，绝大多数业务系统已不再要求兼容IE11。PostCSS插件（如 postcss-custom-properties）对CSS变量的降级支持也早已成熟，但强行降级会丢失动态能力，得不偿失。
- 若项目仍需支持IE11，正确做法是：核心UI用Sass变量保底，动态交互部分用CSS变量+特性检测（
CSS.supports('property', '--color')）做降级分支 - 不要用PostCSS把所有
var(--x)都转成硬编码值——这等于放弃CSS变量的核心价值，又引入编译复杂度 - 真正容易被忽略的点：CSS变量名大小写敏感，
--Color和--color是两个变量；而Sass变量名不区分大小写（$Color===$color），迁移时极易因命名不一致导致未定义行为
