SCSS编译后CSS顺序由AST遍历决定而非源码行序：@import按解析顺序合并、@mixin仅在@include处插入、嵌套与&展开生成同级节点、Dart Sass深度优先遍历但受动态指令影响，顺序不可单凭源码预测。
SCSS 编译后 CSS 规则的顺序与源码书写顺序不一致，不是 bug，而是编译器按语义解析 AST 后线性输出的结果——@import、嵌套展开、@mixin 展开、变量求值等阶段都会重排节点位置，最终顺序由 AST 遍历路径决定，而非源文件行号。
SCSS 编译器如何处理导入顺序
SCSS 不是“从上到下逐行翻译”，而是先收集所有 @import 节点，递归解析成一棵扁平化的 AST。这意味着：
-
@import的位置不影响实际加载顺序：即使写在文件末尾，只要被解析到，就会提前合并进主 AST - 多个
@import的相对顺序才关键，比如@import "base"; @import "components";会保证base中的变量/混合器在components中可用 - 如果用
@use（Dart Sass 推荐），则完全隔离作用域，不会自动拼接 CSS 输出顺序——此时 CSS 顺序取决于你显式@include或引用的地方 - 常见误判：把
main.scss里先写@import "theme/dark"后写@import "layout/grid"，就以为 dark 样式一定在 grid 前面；实际上只要grid内部没依赖dark变量，两者在 AST 中就是并列兄弟节点，输出顺序由遍历顺序定，未必和 import 行序一致
嵌套与 & 符号如何影响最终 CSS 选择器位置
嵌套规则本身不改变输出顺序，但 & 的展开方式会间接导致选择器“跳位”：
- 普通嵌套如
.card { p { color: red; } }编译为.card p { color: red; }，位置由父节点在 AST 中的位置决定 - 但带
&的写法，例如.btn { &--primary { color: blue; } &.is-active { opacity: .8; } }，会生成两个独立规则：.btn--primary和.btn.is-active，它们在 AST 中是同级子节点，顺序取决于源码中&--primary和&.is-active的书写顺序 - 容易踩坑：如果你在某个 mixin 里多次
@include同一个嵌套块，每次调用都会插入新节点，可能打乱原本的层级预期 - 没有“嵌套深度优先”的排序逻辑：编译器不会因为某段嵌套更深，就把它往后推；它只忠实反映你在 AST 中构造出的父子关系
Dart Sass 的 AST 遍历策略决定了最终 CSS 行序
Dart Sass（当前主流实现）对 AST 的遍历是深度优先 + 兄弟节点按源码声明顺序访问，但以下操作会打破直观顺序：
立即学习“前端免费学习笔记（深入）”；
-
@mixin定义本身不产出 CSS，只有@include处才插入节点——所以@include出现在哪，对应 CSS 就出现在哪，跟@mixin定义位置无关 -
@function调用会在解析期求值，结果直接替换进属性值，不产生新规则，但可能让某条规则提前或延后“落地”（比如计算出的z-index影响层叠上下文） -
@if/@for等控制指令生成的规则，其顺序严格按执行流顺序插入 AST，但循环体内部若含嵌套或&，仍需按上述规则再展开 - 最隐蔽的一点：Dart Sass 会对重复的空规则、无效果的
@extend做剪枝，导致某些本该出现的 CSS 段落消失，进一步削弱“源码即顺序”的直觉
真正需要关注的不是“为什么顺序变了”，而是“哪些机制会导致顺序不可控”：动态 @import、跨文件 @use + @forward、条件 mixin 展开、以及大量使用 & 生成变体类——这些地方最容易出现样式覆盖失效或层叠异常，调试时得直接看编译后的 CSS 文件，而不是凭源码位置猜。
