7-1架构核心是明确修改边界而非目录数量：base/放全局重置与CSS变量，utils/存纯逻辑工具，components/按视觉单元拆分，pages/仅做页面覆盖，themes/专注换肤变量——边界清晰才防样式失控。
因为不按7-1架构组织，大型项目里的样式会迅速失控——变量定义在三个地方、按钮样式散落在pages/home.scss和components/_card.scss里、改个断点要 grep 全局，最后谁都不敢动 _mixins.scss。
SCSS @import 顺序错乱直接导致编译失败
SCSS 不是模块系统，main.scss 里每行 @import 就是线性拼接代码。变量、mixin、函数必须先声明后使用，顺序一错就报 Undefined variable "$breakpoints" 或 Undefined mixin "respond-to"。
-
@import 'abstracts/variables';必须在最前，所有其他层都依赖它 -
@import 'abstracts/mixins';必须紧随其后，因为_mixins.scss里要用到$breakpoints -
@import 'vendors/normalize';要放在base/reset之前，否则第三方样式会覆盖重置规则 -
pages/必须永远在最后——它只做覆盖，不能被其他层依赖
utils/ 和 components/ 的职责边界一旦模糊，项目就难维护
utils/（或 abstracts/）不是“放杂项的地方”，它是纯逻辑层：只存 $colors、@function em($px)、@mixin respond-to($bp) 这类不输出 CSS 的抽象工具。
- ❌ 错误：在
utils/_mixins.scss里写@mixin card-shadow { box-shadow: ... }——这是视觉表现，属于components/_card.scss - ✅ 正确：把
card-shadow放进components/_card.scss，并在其中调用@include respond-to(md)和map-get($shadows, sm) - ⚠️ 隐患：如果
utils/_functions.scss里有递归颜色计算函数但没加@if global-variable-exists($cache)缓存，每次编译都会重复执行，构建时间明显变长
components/ 文件粒度决定样式是否可预测
每个 _button.scss、_modal.scss 应该是一个**视觉上可独立存在**的单元，且只负责自己：结构（BEM）、状态（&.is-open）、响应式（@include respond-to(sm)），不跨文件引用，也不依赖 pages/。
立即学习“前端免费学习笔记（深入）”；
- ❌ 错误嵌套：
.header { .nav { &__item { ... } } }编译后选择器权重高（.header .nav .nav__item），后续页面覆盖时不得不加!important或更深层嵌套 - ✅ 推荐写法：
.nav__item { ... }平铺定义，靠引入顺序和选择器简洁性控制优先级 - ⚠️ 注意：
pages/home.scss里只能写.home-hero { ... }这类覆盖规则，不能定义新 mixin、不能修改$theme-colors，否则主题切换会失效
真正让7-1架构起作用的，从来不是目录数量，而是每个文件夹里那条看不见的“修改边界”——越早明确谁该写什么、谁不该碰什么，后期协作和重构就越少踩坑。
