scss变量无法运行时修改，因其仅在编译阶段存在并被替换为固定值；动态主题必须依赖css自定义属性（如--primary-color），由scss生成:root声明，js通过setproperty或data-theme切换，组件样式统一用var()引用。
SCSS变量无法在运行时修改，这是硬限制
SCSS变量（如 $primary-color）只存在于编译阶段。一旦生成CSS，所有 $ 变量都被替换成具体值，比如 #3498db，浏览器里根本看不到变量名，自然没法用JavaScript去改它。
这意味着：你在代码里写 $theme: dark !default; 或用 @if 做主题分支，最终也只会输出一套静态CSS——换主题就得重新构建、刷新页面，做不到“点击切换、即时生效”。
- 常见错误现象：改了
document.documentElement.style.setProperty('--theme', 'dark')，但样式没变，因为压根没引用var(--theme) - 性能影响：纯SCSS主题方案通常要加载多套CSS文件或靠class切换大量规则，重绘开销大、FOUC风险高
CSS自定义属性是唯一能在运行时响应式更新的CSS机制
--main-color 这类CSS变量是浏览器原生支持的，只要它被 var(--main-color) 引用，且作用域正确（通常设在 :root），JavaScript一调用 setProperty，所有关联样式立刻重计算，不触发DOM重排。
但它自己不能做颜色明暗计算、不能条件导出、也不方便跨文件复用逻辑——这些恰恰是SCSS的强项。
- 使用场景：深色模式开关、用户自定义配色、A/B测试主题灰度发布
- 容易踩的坑：忘记在
:root初始化所有变量，导致var(--x, fallback)失效；或在子组件里重复声明同名变量却没处理继承链
把SCSS当“编译器”，把CSS变量当“运行时总线”
真正高效的协作方式，是让SCSS负责“生成逻辑”，而不是“承载状态”。比如：
// _tokens.scss
$color-brand: #3498db;
$color-bg-light: #ffffff;
$color-bg-dark: #1a1a1a;
:root {
--color-brand: #{$color-brand};
--color-bg: #{$color-bg-light};
}
[data-theme="dark"] {
--color-bg: #{$color-bg-dark};
}
这样，设计系统里的所有计算（比如 lighten($color-brand, 10%)）仍在SCSS里完成，输出结果再注入CSS变量；而切换主题只需JS切 data-theme，或直接改 style.setProperty。
- 参数差异：SCSS变量支持类型检查（
type-of($x) === 'color'），CSS变量全是字符串，需靠命名约定和文档约束 - 兼容性影响：CSS变量IE11不支持，但SCSS编译后的CSS完全兼容；所以混合方案中，降级策略得明确——比如给
background-color同时写死值和var()
模块化管理时，SCSS文件结构决定维护成本
变量集中管理不是靠“一个 _variables.scss 文件”，而是按语义分层：设计令牌（colors、spacing）、组件令牌（button-padding、card-radius）、状态令牌（hover-opacity、disabled-filter）。
每层都用SCSS生成对应CSS变量，再通过 @import 控制依赖顺序。否则很容易出现：改一个 $spacing-sm，结果按钮内边距、卡片阴影偏移、动画时长全乱了。
- 容易被忽略的地方：没有用
!default声明基础变量，导致下游库覆盖失败；或者在多个@import链路中意外重复定义同一CSS变量，造成浏览器解析冲突 - 真实痛点：团队协作时，设计师给的Figma样式值直接进SCSS变量，但前端忘了同步更新CSS变量的初始化语句，导致JS读取
getComputedStyle拿到的是空字符串
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
