不决定。SCSS中@import顺序不决定最终CSS输出顺序，Dart Sass按AST遍历路径（深度优先+声明顺序）输出规则，变量/mixin依赖会触发节点重排；应改用@use + @include显式控制插入位置。
SCSS里@import的顺序真的决定CSS输出顺序吗
不决定。@import只是告诉编译器“把这些文件的内容合并进来”，但最终CSS规则的排列顺序由Dart Sass遍历AST节点的路径决定，不是源码里@import出现的先后行序。
常见错误现象：在main.scss中先写@import "base"、后写@import "components"，结果.btn样式却盖过了.reset——这往往是因为components.scss里用了@extend %reset，而%reset定义在base.scss中，Sass为保证语义正确，会把%reset的声明提前到所有@extend之前输出，打乱你肉眼看到的顺序。
- 多处
@import之间没有依赖关系时，它们在AST中是并列兄弟节点，输出顺序取决于编译器遍历顺序（深度优先 + 源码声明顺序），但不可靠 - 一旦存在变量/混合器/mixin调用依赖，Sass会重排节点确保可用性，此时你写的
@import位置反而失效 - 纯CSS文件（如
normalize.css）被@import进来，会被当作普通样式插入，但无法参与变量作用域，容易引发覆盖冲突
用@use + @include替代@import来掌控输出时机
@use不会自动拼接CSS，只建立模块引用；真正生成CSS的位置，是你显式@include或@extend的地方——这才是可控的锚点。
例如你有_mixins.scss和_theme.scss，都只导出@mixin或%placeholder，不直接写样式规则：
立即学习“前端免费学习笔记（深入）”；
// _mixins.scss
@mixin card-shadow {
box-shadow: 0 2px 4px rgba(0,0,0,.1);
}
// _theme.scss
%text-primary {
color: #333;
}
然后在入口index.scss中按需调用：
// index.scss
@use 'mixins';
@use 'theme';
.card {
@include mixins.card-shadow;
@extend %text-primary;
}
-
@use必须放在文件顶部，且每个模块只加载一次，避免重复注入 - 所有
@include和@extend都发生在index.scss内，CSS输出顺序就完全由你书写这些调用的顺序决定 - 注意：
@use默认启用命名空间（如mixins.card-shadow），加as *可取消，但易造成命名污染
Webpack构建中CSS注入顺序错位怎么修
即使SCSS层顺序正确，Webpack仍可能让CSS在DOM里乱序插入，典型原因是mini-css-extract-plugin动态追加<style>标签，尤其在HMR热更新时。
关键检查点：
- 确保只有一个样式入口，例如
entry: { app: ['./src/index.js', './src/styles/index.scss'] }，不要分散成多个@import或多个import语句 - 禁用
mini-css-extract-plugin的hmr选项：hmr: false，否则热更新会不断追加新<style>，旧的不移除 - 如果用了
style-loader（开发环境），确认它没和其他CSS loader冲突；生产环境务必用mini-css-extract-plugin提取，别混用 - 检查
splitChunks配置，避免把公共样式拆进不同chunk，导致加载时机不可控
为什么改了SCSS却看不到CSS顺序变化
最常被忽略的是缓存和构建链路断裂：你改了@include顺序，但浏览器加载的还是旧CSS；或者source map没配好，你以为改了A文件，实际生效的是B文件里的同名规则。
排查步骤：
- 清空
node_modules/.cache和dist目录，重新全量构建，排除loader缓存干扰 - 打开浏览器开发者工具的Network面板，确认加载的CSS文件时间戳最新，且HTTP响应头没有
304 Not Modified - 检查
sourceMappingURL是否真实存在并可访问，点击CSS规则旁的文件名，看能否跳转回对应SCSS行——跳不到就说明构建链路某环丢了map - 在终端运行
sass --version，确认是Dart Sass（非已停更的Node Sass），老版本AST行为差异大，容易误判
