@use 替代 @import 是构建高效 Sass 布局框架的起点，它通过命名空间隔离变量/混入、杜绝隐式覆盖、支持未用代码剔除；layout/ 仅含容器关系类文件（如\_grid、\_container），不含组件语义内容；应禁用 @extend 防止选择器污染，改用 @include 复用布局逻辑。
直接用 @use 替代 @import，再配合抽象层（abstracts/）和布局层（layout/）分离，是构建高效 Sass 布局框架最实际的起点。老式 @import 会污染全局作用域，导致变量覆盖、样式不可预测，而 @use 强制显式引用，让每个模块的依赖一目了然。
为什么 @use 是布局模块化的前提
传统 @import 下，_variables.scss 被多个文件重复引入，一旦某个组件文件（比如 _cards.scss）意外重定义了 $primary-color，整个主题就可能崩掉——你根本不知道哪一行改的。
@use 把变量、混入、函数都封装进命名空间，调用必须带前缀：
@use 'abstracts/variables' as vars;
@use 'abstracts/mixins' as mix;
.card {
border-color: vars.$border-color;
@include mix.flex-center;
}
- 所有变量/混入必须通过命名空间访问，杜绝隐式覆盖
- 同一变量在不同模块中可安全复用，比如
vars.$spacing-sm在_buttons.scss和_forms.scss中各自使用，互不干扰 - 编译时自动剔除未使用的变量和混入，减小 CSS 体积
layout/ 目录该放什么、不该放什么
很多人把 layout/ 当成“所有盒子模型”的垃圾桶，结果里面塞了 _header.scss、_grid.scss、_sidebar.scss，甚至还有 _modal.scss ——这已经越界到组件层了。
立即学习“前端免费学习笔记（深入）”；
真正属于 layout/ 的，只处理「容器关系」和「流式结构」：
-
_grid.scss：基于display: grid的响应式栅格系统，含@mixin make-grid-columns()等基础工具 -
_container.scss：定义.container、.container-fluid的宽度、居中与断点逻辑 -
_flex.scss：封装常用 flex 容器行为，如@mixin flex-row()、@mixin flex-col()，不包含具体子项样式 -
_breakpoints.scss：只声明断点变量（$bp-md: 768px），不写媒体查询内容
像页头、侧边栏这类有明确视觉语义和交互行为的，应该归入 components/ 或 sections/，否则布局层会失去抽象能力。
如何避免 @extend 污染布局选择器
有人喜欢用 @extend 给 .layout-main 继承 .flex-col，但这是危险操作——@extend 会在 CSS 输出中把所有引用它的选择器拼成一个长链，比如：
.layout-main, .section-hero, .card-grid { display: flex; flex-direction: column; }
一旦某天 .section-hero 不再需要 flex 列，你就得去翻所有 extend 它的地方。更糟的是，它无法被 @use 隔离。
- 布局类应保持原子性，只声明自身行为（如
display: grid），不继承其他模块 - 用
@include替代@extend：混入生成内联样式，不会跨选择器污染 - 如果真要复用布局逻辑，抽成
@mixin layout-column，并在需要的地方显式@include
真正的难点不在怎么写，而在「谁有权修改 abstracts/_breakpoints.scss」——这个文件一旦被随意调整，所有布局模块都会连锁响应。建议把它设为团队共识文档，每次变更必须同步更新设计系统规范，而不是只改代码。
