main.scss 的 @import 顺序不能调换，因为 SCSS 编译器仅按行序拼接代码，变量、mixin、样式依赖必须严格遵循先后顺序，否则引发隐性崩溃。
main.scss 的 @import 顺序写错，样式就不可预测——这不是编译报错的问题，而是变量未定义、mixin 找不到、页面覆盖失效等隐性崩溃。7-1 架构真正起作用的地方，从来不是“建了七个文件夹”，而是每个目录的修改边界是否被守住。
为什么 main.scss 的 @import 顺序不能调换
SCSS 编译器不做依赖分析，只按 @import 行顺序拼接代码。这意味着：
-
_variables.scss必须在_mixins.scss之前——因为 mixin 里要读$breakpoints -
_mixins.scss必须在_components/button.scss之前——否则@include button-style直接报Undefined mixin -
vendor/normalize.scss必须在base/reset.scss之前——否则第三方样式可能污染重置规则 -
pages/home.scss必须放在最后——它只做覆盖，不提供任何基础能力
典型正确顺序（按依赖链）：
@import 'vendor/normalize'; @import 'base/reset'; @import 'base/variables'; @import 'base/mixins'; @import 'utils/functions'; @import 'layout/grid'; @import 'components/button'; @import 'pages/home';
utils/ 和 base/ 的职责到底怎么划清
这两个目录最容易混用，但混淆后项目越写越难维护。
-
base/是根级基础设施：只放_reset.scss、_typography.scss、:root { --color-primary: #3498db; }这类全局默认值；禁止出现.button或$card-shadow这种带业务语义的内容 -
utils/（或abstracts/）是纯逻辑层：只存_variables.scss（断点 map、主题色 map）、_mixins.scss（@mixin respond-to($bp)）、_functions.scss（@function em($px)）；它不输出任何 CSS，只提供可复用的“工具” - ❌ 错误示例：
utils/_mixins.scss里写@mixin card-shadow——这是components/card.scss的事 - ✅ 正确路径：
components/_card.scss内部调用map-get($shadows, sm)+@include respond-to(md)
components/ 文件粒度与嵌套陷阱
一个文件对应一个视觉上可独立存在的 UI 单元，比如 _button.scss、_modal.scss，但实际编码中容易踩坑：
立即学习“前端免费学习笔记（深入）”；
- 禁止跨组件引用：不要在
_button.scss里@import '../pages/home'，也不该依赖pages/下的任何东西 - 避免深层嵌套：
.header { .nav { &__item { ... } } }编译后是.header .nav .nav__item，权重高、难覆盖；应平铺写成.nav__item - 状态和响应式必须收束在本文件内：
&.is-active、@include respond-to(sm)都写在_button.scss里，不拆到别处 - 不用
!important：靠引入顺序和选择器简洁性解决冲突，否则pages/home无法安全覆盖
themes/ 和 pages/ 的修改边界在哪
这两个目录都负责“覆盖”，但覆盖的对象和方式完全不同：
-
themes/只管变量切换：通过替换一组 CSS 自定义属性或 Sass map（如$theme-colors: (primary: #e74c3c)）驱动整套 UI 变色，不写具体选择器 -
pages/只管局部样式增强：比如home.scss里写.home-hero { padding-top: var(--space-xxl); }，仅限当前页面，不导出变量、不定义新 mixin - ⚠️ 容易忽略的点：如果
themes/_admin.scss里偷偷写了.btn { background: red; }，就破坏了“主题只管变量”的边界，导致换肤逻辑和组件样式耦合
真正的难点不在建目录，而在于每次新增一个 @import、写一个 @mixin、加一层嵌套时，是否清楚自己正在哪个边界内操作。
