必须采用7-1目录结构并明确修改边界，否则文件冗余、维护低效；SCSS中@import顺序决定变量/mixin声明先后，错序导致编译失败；base/只含基础设施，utils/仅存纯逻辑工具，components/按UI单元粒度拆分，禁用深层嵌套与!important，统一用@use+命名空间管理变量作用域。
必须用 7-1 目录结构 + 明确修改边界，否则文件越堆越多，改个按钮样式要 grep 十分钟。
为什么 main.scss 的 @import 顺序不能乱
SCSS 编译器是线性拼接代码，变量、mixin、函数必须先声明后使用。顺序错，@include respond-to(md) 就直接报 Undefined mixin；$breakpoints 若在 _mixins.scss 之后才引入，编译当场失败。
- 严格按依赖链写：
@use "base/variables" as *→@use "base/mixins" as *→@use "utils/functions" as * -
pages/必须放最后——它只做覆盖，不提供任何基础能力 -
vendor/（如 normalize.css）要放在base/reset之前，否则重置规则会被第三方样式覆盖
base/ 和 utils/ 的职责必须一刀切开
base/ 是根级“基础设施”：只放全局重置、:root CSS 变量、排版默认值。这里绝不能出现 .button 或 .card 这类业务语义 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.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，靠选择器权重和@import顺序解决冲突——否则pages/home无法安全覆盖
@use 路径和命名空间漏掉一个就失效
变量写了却没生效，90% 是因为作用域断链。典型错误包括：
- 组件文件里写了
z-index: $z-modal，但根本没@use "src/styles/z-index" - 用了
@use "src/styles/z-index" as z，却写成z-index: $z-modal（漏了z.前缀） - 把变量定义在
:root再用var(--z-modal)，混用 Sass 变量和 CSS 自定义属性，导致维护割裂
正确做法是统一用 @use 并带命名空间：@use "src/styles/z-index" as z;，然后写 z-index: z.$z-modal-overlay;。JS 动态提层时必须同步更新 CSS 变量，否则 Sass 编译完就没了，JS 根本读不到。
