不能靠调整@import顺序控制CSS级联顺序，因其在Dart Sass中被重排为依赖图拓扑序；真正可控方式是用@use隔离作用域，并在单一入口文件中显式拼接规则。
不能靠调整 @import 顺序来控制最终 CSS 级联顺序，它在 Dart Sass 中已被重排为依赖图拓扑序；真正可控的方式是用 @use 隔离作用域 + 在单一入口文件中显式拼接规则。
为什么@import顺序不等于CSS输出顺序
Sass 的 @import 不是文本插入，而是 AST 合并操作。编译器会递归解析所有被导入文件，构建成一棵依赖树，再按拓扑序线性输出——你写的先后顺序只影响变量/混合器的可用性，不影响最终 CSS 规则的位置。
- 常见错觉：
@import "base"; @import "components";就以为.base规则一定在.component前面；实际两者若无直接依赖，AST 中是并列节点，输出顺序由遍历路径决定 - 如果
components.scss里又@import "base"，那base的规则会被“提”到 components 所在位置合并，进一步打乱你的预期 - Webpack + css-loader 还可能把纯 CSS 文件（如
reset.css）当作独立模块异步注入，完全脱离 SCSS 编译流
用@use + 入口文件手动控制拼接
@use 不自动拼接 CSS，只导入命名空间，因此样式输出完全由你在顶层文件中如何组织 @include 或直接书写选择器决定。
- 所有 partial（如
_variables.scss、_mixins.scss）只导出变量/mixin，不直接输出任何 CSS - 创建单一入口文件（如
index.scss），只写@use，不写@import - 按需调用：
@include button-styles();、@include grid-system();，顺序由你控制 - 纯 CSS 文件（如
normalize.css）不要@import，改用 Webpack 的asset/inline或 JS 中import，由style-loader统一注入
@extend和嵌套都会破坏顺序预期
@extend 会把扩展选择器“提”到基础类定义处合并，嵌套展开则生成同级 AST 节点——二者都让 CSS 规则位置脱离源码书写位置。
立即学习“前端免费学习笔记（深入）”；
-
@extend .btn写在_buttons.scss末尾，但最终.btn, .btn-primary规则会出现在_base.scss对应的输出块里 -
.card { &__title { } &--hover { } }会生成两个同级规则：.card__title和.card--hover，它们的顺序取决于源码中&__title和&--hover的书写顺序，而非缩进层级 - 避免在 mixin 里多次
@include同一个嵌套块，每次调用都会插入新节点，可能打断原有顺序
构建工具层也要盯住注入时机
即使 SCSS 层面顺序正确，Webpack 的热更新、chunk 分割或多个 entry 仍可能导致 <style></style> 标签注入 DOM 的顺序错乱。
- 确保单入口：例如
entry: { app: ['./src/index.js', './src/styles/index.scss'] }，避免多入口触发多个 style 标签 - 禁用
mini-css-extract-plugin的hmr选项（设为false），否则热更新时会动态追加<style></style>标签，极易错位 - 若必须多入口，用
optimization.splitChunks.cacheGroups强制把所有 CSS 提取到同一个 chunk 中
真正容易被忽略的是：Sass 编译顺序 ≠ CSS 级联顺序 ≠ 浏览器解析顺序 ≠ DOM 注入顺序——四个环节各自独立，只有一环失控，就可能覆盖失败或样式闪烁。
