大型项目必须用 Sass，因其通过@use实现变量跨文件复用与作用域隔离、支持编译期计算与条件判断、提供模块化依赖审计与循环检测、结合BEM嵌套保障语义与可维护性，并以%mixin和%placeholder精准控制复用边界。
大型项目必须用 Sass，不是因为它“更酷”，而是原生 CSS 在工程层面根本兜不住——变量不可跨文件复用、样式无作用域、逻辑无法抽象、改一处崩三处是常态。
变量跨文件复用与作用域控制
原生 CSS 的 --color-primary 是运行时变量，绑定在 DOM 节点上，不能用在 @media 里做计算，也不能参与 lighten() 或 @if 判断；Sass 的 $primary-color 是编译期常量，哪儿都能用。
- 常见错误：
$spacing-xs: 4px定义在_button.scss里，其他文件@use后报Undefined variable—— 忘记 Sass 变量不自动提升，必须显式@use 'variables' as *或@use 'base/variables' - 真实影响：设计系统换主题时，Sass 改一个
$theme值，全项目编译后自动适配；CSS 自定义属性得靠 JS 注入或手动 patch:root，且媒体查询内无法响应 - 建议：按用途拆分变量文件 ——
_colors.scss、_breakpoints.scss、_z-index.scss，@use时按需引入，避免无用代码注入
@use 与模块化依赖可审计
原生 @import 是同步阻塞加载，每个都触发解析开销；Sass 的 @use 是静态依赖声明，支持循环依赖检测，构建时就能报错。
- 典型卡点：
A @uses B，B @uses C，C @uses A→ Dart Sass 直接报错Invalid operation: A tried to load B, but B already tried to load A - Less 不报错但静默失效，得靠目录结构提前规避；Sass 强制你理清依赖链
- 路径别名（如 Webpack 的
resolve.alias）必须配，否则@use '../../../styles/mixins'写到第 5 层就没人敢动了
嵌套与 BEM 结合的可控性
嵌套本身没问题，问题出在开发者误以为 HTML 结构 = CSS 语义。Sass 编译后生成的选择器权重和可维护性，完全取决于你怎么用 &。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
立即学习“前端免费学习笔记（深入）”；
- 踩坑示例：
.card { div { color: red; } }编译成.card div，HTML 加个 wrapper 就失效；正确写法是.card { &__header { } &__body { } }，输出.card__header，语义清晰、不依赖 DOM 深度 - 性能提示：嵌套超 3 层，gzip 后 CSS 体积实测增加 15%~30%；复杂状态建议用类名组合（如
.btn.is-loading），而非.btn:hover:active::before多层嵌套 -
@at-root要会用：想把&.is-active提升到顶层？写@at-root #{&}.is-active { ... }，别硬塞进深层嵌套里
Mixin 与 %placeholder 的复用边界
@mixin 是复制粘贴，@extend %placeholder 是选择器合并——选错直接导致 CSS 体积膨胀或 specificity 混乱。
- 反面案例：用
@extend %clearfix给 50 个组件扩展，编译出.a, .b, .c, ..., .z::after这种超长列表，调试困难，权重失控 - 正向用法：
%text-truncate这种纯静态规则适合@extend；带参数的动态逻辑（如@mixin responsive-font($base)）必须用@mixin - Less 里慎用
.flex-center这类通用类——它把样式逻辑从组件层搬到了 HTML 层，破坏封装，团队协作时谁加谁删根本不可控
真正卡住大型项目的，从来不是“怎么写 Sass”，而是“谁改了什么、影响了谁”。Sass 的价值不在语法糖，而在它提供的工具链能让你看清依赖、锁死作用域、量化复用成本——这些事，原生 CSS 做不了，也不该让它做。
