原生css变量在vite中无需编译，运行时动态生效，支持javascript读写、主题切换和calc()实时计算；预处理器变量则需完整构建流程，修改后触发全量重编译与整页刷新，调试体验和性能均逊于css变量。
原生CSS变量在Vite中无需编译，而预处理器变量必须走构建流程——这是性能和调试体验的根本分水岭。
预处理器变量的转换链路太长
每次改一个 $color-primary，Sass 必须完整走一遍：文件读取 → 语法解析 → 变量替换 → 嵌套展开 → @mixin 展开 → 输出 CSS → 注入 DOM。这个过程在 Vite 的 dev server 中虽快（esbuild 加速），但仍是同步阻塞的；而 --color-primary 修改后，浏览器只触发 CSSOM 更新，不重跑 JS、不重解析 HTML、不触发热重载整个模块。
- 修改
$spacing-sm后，所有引用它的 .scss 文件都会被重新编译（即使只改了一个值） - 修改
--spacing-sm后，仅当前元素或其后代样式重计算，DevTools 的 “Styles” 面板里能直接看到实时生效 - Vite 的 HMR 对预处理器文件支持有限：改 variables.scss 通常会触发整页刷新，而非局部更新
fallback 和作用域行为差异导致调试错觉
很多人以为 var(--color, #333) 和 Sass 的 $color: #333 !default 是等价的，实际不是。前者只在 --color **未声明** 或 **值非法**（如 --color: 123）时才用 fallback；一旦父级写了 style="--color: blue"，子元素 color: var(--color, #333) 就取 blue，#333 完全不生效。
- Sass 的
!default是编译期静态决策，无继承干扰 - CSS 变量是运行时动态查找，受
inherit、initial、unset影响极大 - DevTools 里 hover
var(--x)显示的是最终计算值，但点不开“从哪来”，不如 Sass source map 直接跳转到variables.scss
构建产物体积和压缩效果相反
预处理器编译后，$size * 2 变成 32px，Terser 能把它和其它数值一起压缩；而 calc(var(--size) * 2) 里的 var(--size) 是字符串，Terser 不动它，且每个 var() 都是独立运行时查找，Chrome 的 Rendering 面板开启 “Paint flashing” 后，频繁切换主题会明显看到重绘区块。
- 大量使用
var(--x)的 CSS 文件，gzip 后体积可能比 Sass 编译结果还大（因重复字符串未合并） - PostCSS 插件如
postcss-custom-properties可静态降级，但它无法处理calc(var(--a) + var(--b))这类组合 - 真正轻量的方案是混合使用：颜色/主题用 CSS 变量，间距/断点/函数逻辑仍走 Sass，避免非此即彼
最易被忽略的一点：CSS 变量的响应式断点复用（@media (min-width: var(--sm))）目前仅 Chrome 119+、Firefox 120+ 支持，旧版浏览器直接忽略整条媒体查询——这不是 polyfill 能补的，得靠构建时回退到硬编码值，反而让配置更复杂。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
