Sass & SCSS

支持嵌套声明、变量、混合宏 (类似于函数，可以将常用的样式块封装起来并在多个地方调用，甚至支持参数传递) 等

为什么浏览器不直接兼容 SCSS ？

这是一个非常深刻的问题，触及了 Web 标准演进的核心逻辑。浏览器不直接兼容 SCSS，本质上是因为“工程化需求”与“浏览器执行效率”之间的矛盾。

以下是几个核心原因：

浏览器（如 Chrome、Safari）的渲染引擎（如 Blink、WebKit）核心目标是极其快速地解析并渲染页面。

CSS 是简单的： 原生 CSS 规则是声明式的（Declaration），解析器只需要根据选择器匹配 DOM 节点，过程线性且非常高效。
SCSS 是逻辑化的： 如果浏览器直接支持 SCSS，它就必须内置一个完整的“Sass 编译器”。这不仅意味着需要处理变量作用域、函数计算、递归 Mixin、循环渲染等复杂的编程逻辑，还会大幅增加浏览器的体积和内存占用，导致页面渲染速度变慢。

Web 的基石是 W3C 标准。任何想要被浏览器实现的功能，都必须经过极其漫长的“提案 -> 草案 -> 候选推荐 -> 标准化”流程。

Sass 是“社区先行”的产物： SCSS 的功能（变量、嵌套等）是在 Sass 社区中通过迭代进化出来的，目的是解决开发者的痛点。
标准化的滞后性： W3C 往往会在社区方案成熟且被广泛验证后，将其“吸收”进原生 CSS。
- 例子： 以前我们需要 Sass 来定义 padding: $var；现在浏览器已经原生支持了 CSS 变量 (Custom Properties)，语法是 --main-color: #333;。
- 例子： 以前需要 Sass 处理嵌套（Nesting）；现在最新版本的 CSS 规范已经原生支持嵌套了。

在现代 Web 开发中，我们实际上是在利用 “编译时（Build-time）”来换取“运行时（Run-time）”的性能。

编译时的自由： 在开发阶段，你可以使用各种复杂的函数、逻辑、文件拆分，这让代码结构非常清晰，易于维护。
运行时的纯粹： 编译工具（如 Vite, Webpack）在打包时，会将这些复杂的 SCSS 逻辑转化为最纯粹、浏览器最容易理解的 CSS 代码。
- 比如，所有的 Mixin 会被展开，所有的变量会直接被替换为计算好的值。

这就像编写 TypeScript 一样——浏览器不直接运行 TS，因为它需要被转换为 JS。这种做法允许开发者使用更高级的语法特性，同时保证用户在最终页面上获得最高效的执行体验。