SCSS是编译期样式逻辑的唯一落点，因其变量、@if、@each、@use等能力支持构建时决策，而原生CSS变量仅运行时生效，无法参与条件判断或函数运算，且@use机制为构建工具提供依赖分析锚点。
因为原生 CSS 无法在构建时做逻辑决策，而 SCSS 的变量、@if、@each、@use 等能力，是编译期样式逻辑的唯一落点。
SCSS 变量能参与编译期判断，原生 CSS 变量不能
原生 --color-primary 是运行时值，浏览器渲染时才解析，所以它不能用在 @if 条件里，也不能传给 darken() 这类函数。而 SCSS 的 $theme 在编译阶段就确定了类型和值：
- 可写
@if $theme == "dark" { ... }，直接剔除 light 主题的整段 CSS - 可用
scale-color($base, $lightness: +20%)批量生成调色板，输出的是纯静态 CSS，无 JS 运行时开销 - 若把这类逻辑搬到 JS 里动态注入样式，SSR 渲染会丢失样式，tree-shaking 也失效
SCSS 的 @use 和 @forward 是构建工具依赖图的锚点
Webpack、Vite、TurboPack 这些构建工具靠 @use 识别模块依赖，实现增量编译和公共 chunk 提取：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
-
@use "shared/typography" with ($font-stack: "Inter");—— 同一模块被多处@use，但只编译一次 -
@forward "theme/colors" as theme-*;—— 控制导出符号粒度，避免下游误用未文档化的内部变量 - 原生
@import或@layer不提供作用域隔离、参数注入或副作用控制，构建工具无法据此做依赖分析
嵌套、Mixin、主题条件编译仍是运行时不可替代的工程需求
原生嵌套（& 语法）虽已支持，但它不解决以下问题：
立即学习“前端免费学习笔记（深入）”；
- 嵌套深度超过 4 层后，CSS 选择器权重爆炸，且无法用
&:hover+ BEM 混合生成.btn--primary:hover这类语义化类名 - 一个按钮组件需要同时支持暗色/高对比度/RTL 多种上下文？用
@mixin button-variant($mode)封装比写一堆@media (prefers-contrast: high)+[dir="rtl"]组合更可控 - 设计系统要求所有间距必须来自
$spacing-map: ("sm": 0.25rem, "md": 0.5rem, ...)？只有@each能批量生成.p-md { padding: 0.5rem; }类，且确保无遗漏、无拼写错误
真正容易被忽略的点是：这些能力不是“让写 CSS 更爽”，而是构建流水线里真实的逻辑节点——它们决定最终产物的体积、结构、可缓存性，以及 SSR/边缘渲染能否正确输出首屏样式。一旦放弃编译期控制权，就等于把样式治理降级为运行时修补。
