7-1架构的核心是明确修改边界而非目录数量，main.scss的@import顺序不能乱，因scss按行拼接代码，变量、mixin、函数须先声明后使用，否则报错；vendor/需在base/reset前，base/variables必须在base/mixins前，utils/functions须在依赖它的文件前，pages/必须置于最后。
直接说结论：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/必须放在最后——它只做覆盖，不提供基础能力
utils/和base/的职责到底怎么划
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/不是“换肤开关”，而是设计令牌的集合；pages/不是“页面样式随便塞”，而是严格限于覆盖与换肤，不得越界定义样式或逻辑。
- ❌ 错误：
pages/home.scss里写@mixin hero-animation或.card新样式 - ✅ 正确：
pages/home.scss只写.home-hero { margin-top: 2rem; }这类局部覆盖 - 真正难的不是建目录，而是每次新增文件时都得问一句：“这个东西，到底该归谁管？”——边界模糊处，就是未来冲突爆发点
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
