7-1模式核心是明确修改边界：base/仅放全局重置与CSS变量，utils/只存变量/mixin/函数等纯逻辑工具，components/按视觉单元拆分且禁止嵌套过深，pages/和themes/严格限于覆盖与换肤，不得越界定义样式或逻辑。
7-1 模式不是目录数量游戏，而是靠明确的修改边界防止样式失控——照搬结构但放错文件，项目反而更难维护。
main.scss 的 @import 顺序为什么必须严格按依赖链写
SCSS 编译时按 @import 行顺序拼接代码，变量、mixin、函数必须先声明后使用。顺序错，@include button-style 就会报 Undefined mixin；$breakpoints 若在 _mixins.scss 之后引入，就直接编译失败。
- vendor/（如
normalize.css）必须放在base/reset之前，否则重置规则被第三方样式覆盖 -
base/variables必须在base/mixins之前，因为 mixin 常依赖变量 -
utils/functions必须在所有用到它的mixins或components之前 -
pages/必须放在最后——它只做覆盖，不提供基础能力
base/ 和 utils/ 的职责边界在哪
base/ 是根级“基础设施”：只放全局重置、:root CSS 变量、默认排版、根字体。这里不能出现任何组件名或业务语义 class（比如 .card、.header-nav）。
utils/（也叫 abstracts/）是纯逻辑层：只存 _variables.scss（断点 map、主题色）、_mixins.scss（@mixin respond-to($bp)）、_functions.scss（@function em($px)）。它不写样式，只提供可复用的“工具”。
立即学习“前端免费学习笔记（深入）”；
- ❌ 错误：
utils/_mixins.scss里写@mixin card-shadow——这是components/card的事 - ✅ 正确：
components/_button.scss里用@include respond-to(md)+map-get($shadows, sm) - ⚠️ 性能注意：
_functions.scss中递归函数（如颜色明度计算）若没加@if global-variable-exists()缓存，每次调用都会重新编译，拖慢构建
components/ 文件粒度与嵌套陷阱
每个 .scss 文件应对应一个**视觉上可独立存在**的 UI 单元，比如 _button.scss、_modal.scss。文件内禁止跨组件引用，也不该依赖 pages/ 下的任何东西。
- 一个文件只负责一个组件的全部样式：结构（BEM 命名）、状态（
&.is-active）、响应式（@include respond-to(sm)） - 避免深层嵌套：
.header { .nav { &__item { } } }编译后是.header .nav .nav__item，权重高、难覆盖；改用.nav__item平铺写法更可控 - 禁止在
components/中定义新变量或 mixin —— 它们只消费utils/和base/提供的能力
themes/ 和 pages/ 容易被当成“兜底目录”来滥用
themes/ 不是“换肤开关”，而是设计令牌的集中输出层：只存主题变量（$theme-colors）、CSS 自定义属性映射（--color-primary: #3498db），不包含任何选择器或样式规则。
pages/ 不是“页面样式集合”，而是仅限覆盖：只写 .home-hero { margin-top: 2rem; } 这类低权重、高特异性规则，不允许 @include 组件 mixin，更不能定义新 $variable。
- ❌ 错误：
pages/home.scss里写@mixin home-banner-layout—— 这属于layout/或components/职责 - ❌ 错误：
themes/_admin.scss里直接写.admin-sidebar { width: 240px; }—— 应通过变量驱动，由components/sidebar消费 - ⚠️ 最容易被忽略的一点：当团队开始往
pages/塞组件逻辑时，说明components/的抽象粒度已经失衡，此时重构比补丁更有效
