7-1架构核心是明确修改边界而非目录数量：base/放全局重置与CSS变量，utils/存纯逻辑工具，components/按视觉单元拆分，pages/仅做页面覆盖，themes/专注换肤变量——边界清晰才防样式失控。
7-1 模式不是目录数量游戏，而是靠明确的修改边界防止样式失控——照搬结构但放错文件，项目反而更难维护。
main.scss 的 @import 顺序为什么不能乱
SCSS 编译时按 @import 行顺序拼接代码，变量、mixin、函数必须先声明后使用。顺序错，@include button-style 就会报 Undefined mixin；$breakpoints 在 _mixins.scss 里被引用，但它若在 _variables.scss 之后引入，就直接编译失败。
- 必须严格按依赖链引入：先
@import 'base/variables'，再@import 'base/mixins'（它依赖变量），然后是@import 'utils/functions'（依赖 mixins） -
pages/必须放在最后——它只做覆盖，不提供基础能力 -
vendor/（如normalize.css）要放在base/reset之前，否则重置规则会被第三方样式覆盖
base/ 和 utils/ 的职责怎么划清
base/ 是根级“基础设施”：只放全局重置、根字体、排版默认值、CSS 自定义属性（:root { --color-primary: #3498db; }）。这里不能出现任何组件名或业务语义 class。
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/_card.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平铺写法更可控 - 组件内不要用
!important，靠选择器权重和引入顺序解决冲突——否则pages/home无法安全覆盖
themes/ 和 pages/ 的修改边界在哪
themes/ 只管“换肤”：通过切换一组变量（$theme-colors、$font-family）驱动整个 UI 变化，所有组件都应从 utils/variables 或 themes/ 读值，而不是硬编码。
pages/ 只做“页面专属覆盖”：比如首页轮播图高度微调、后台页表格行高压缩。它不定义新变量、不导出 mixin、不封装新组件。
- ✅ 允许：
pages/_home.scss中写.hero-banner { height: calc(100vh - 64px); } - ❌ 禁止：
pages/_home.scss中写@mixin home-hero-layout或$home-spacing - ⚠️ 关键细节：当项目加入暗色模式时，
themes/_dark.scss应只覆盖变量，而非重写整套组件样式——否则维护成本翻倍
真正让 7-1 架构起效的，从来不是目录建得全不全，而是每次新增一个 _xxx.scss 文件时，你能否 3 秒内判断它该进哪个目录、以及它能不能被其他目录安全引用。边界模糊的地方，就是未来 git blame 时最头疼的 commit。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
