7-1架构中“7”指base、layout、components、pages、themes、utils、vendor七个源文件夹，“1”是仅负责@import的入口main.scss；核心在于职责隔离与修改边界，而非目录数量。
SCSS 的 7-1 架构不是强制规范，而是为解决样式膨胀和团队协作混乱而设计的分层约束——直接照搬目录结构但忽略“职责隔离”原则，反而会让项目更难维护。
什么是 7-1 架构里的“7”和“1”
“7”指 base、layout、components、pages、themes、utils、vendor 七个源文件夹；“1”是最终入口文件 main.scss，只负责 @import。关键不在数量，而在每个目录必须有明确的“修改边界”：
-
base/：仅放重置（_reset.scss）、默认 typography（_typography.scss）、根级 CSS 变量（_variables.scss）——这里不能出现任何组件相关 class -
components/：每个文件对应一个可复用 UI 单元（如_button.scss），禁止依赖pages/或具体业务逻辑 -
pages/：只写页面级覆盖规则（如home.scss中的.home-hero { … }），不允许定义新 mixin 或变量
为什么 @import 顺序决定样式是否可预测
SCSS 编译时按 @import 顺序拼接代码，顺序错乱会导致变量未定义、样式被意外覆盖。入口 main.scss 必须严格按依赖层级引入：
@import 'base/reset'; @import 'base/variables'; @import 'base/mixins'; // 依赖 variables @import 'utils/functions'; // 依赖 mixins @import 'layout/grid'; @import 'components/button'; @import 'pages/home'; // 最后才引入页面专属样式
常见错误：pages/home 提前引入，导致它里面的 @include button-style 找不到定义；或把 vendor（如 normalize.css）放在 base/reset 之后，造成重置失效。
utils/ 目录最容易被滥用
这个目录本意是存放纯逻辑抽象：函数（em()、respond-to()）、mixin（clearfix、visually-hidden）、全局工具类（.u-mt-2）。但实践中常被塞进半成品组件或业务规则：
- ❌ 错误：在
utils/_mixins.scss里写@mixin card-shadow { box-shadow: 0 2px 8px rgba(0,0,0,0.1); }——这是components/card的职责 - ✅ 正确：只放
@mixin respond-to($breakpoint) { @media (min-width: map-get($breakpoints, $breakpoint)) { @content; } } - 性能影响：
utils/functions中的递归函数（如颜色明度计算）若无缓存，会在每次调用时重复编译，拖慢构建速度
当项目变大时，真正的分层难点不在目录，而在作用域泄漏
SCSS 的嵌套和 & 符号极易隐式扩大选择器权重，比如 .header { .nav { &__item { … } } } 编译后是 .header .nav .nav__item，比独立写的 .nav__item 难以覆盖。更隐蔽的问题是：
- 多个
components/文件都定义了同名$spacing-unit变量，靠@import顺序覆盖，但没人记得谁先谁后 -
themes/切换时，用!default声明的变量可能被低层级文件意外重写 - 没有启用
module系统（Dart Sass 1.23+）的项目，所有@use和@forward都无效，只能退回脆弱的@import模型
这时候，目录结构再标准也没用——分层管理的本质，是让每一行 CSS 都能清晰回答“它属于哪一层、被谁消费、能否被安全删除”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
