混用@use和@import必然导致css输出顺序失控，因sass检测到任意@import即整文件降级为legacy模式，忽略所有@use、失效命名空间，并使样式拼接逻辑崩坏；删掉残留@import（含第三方库及构建配置中注入）即可恢复模块化行为与可控顺序。
@use 和 @import 混用会直接导致 CSS 输出顺序失控，不是“可能错乱”，而是必然错乱——Sass 一旦检测到任意 @import，整份文件立即降级为 legacy 模式，所有 @use 被忽略，命名空间失效，样式拼接逻辑彻底崩坏。
为什么删掉一行 @import 就能修复顺序
Sass 编译器对 @import 是零容忍的：哪怕只有一处 @import "reset" 或第三方库残留（如 Bootstrap 5.2 及更早版本），当前文件及其所有依赖链都会退化为扁平作用域。此时：
-
@use "vars" as v不生效，v.$color-text报Undefined variable - 所有被
@import进来的样式直接 inline 到当前文件末尾，完全脱离你写的@use顺序 - Webpack 的
style-loader会把这部分 legacy 样式当作独立模块异步注入，DOM 中的<style></style>标签位置不可控
如何定位并清理所有 @import 残留
别只搜主文件，要查整个依赖链——被 @import 的文件，哪怕它自己只写 @use，也会被拖进 legacy 模式：
- 全局搜索项目中所有
@import（包括单/双引号、带不带.scss、下划线前缀是否一致） - 重点检查：
node_modules中未升级的第三方库（如bootstrap@5.2）、vue.config.js或vite.config.js里的sassOptions.additionalData是否偷偷注入了@import - 用
sass --version确认是 Dart Sass ≥ 1.23.0；LibSass 已废弃，不支持@use，会直接报错而非警告
@use 正确组织样式的最小可行结构
真正控制 CSS 输出顺序的，不是导入语句本身，而是“哪些规则最终落在顶层入口文件里”：
- 入口文件（如
index.scss）只写@use，不写任何@import，也不直接写选择器 - 所有分量文件（
_button.scss、_card.scss）以_开头，只导出@mixin或占位符（%base），不输出任何 CSS 规则 - 在
index.scss中按需@include button-styles()或@extend %base，顺序由你手写决定 - 纯 CSS 文件（如
normalize.css）不要@import，改用<link rel="stylesheet">或 Webpack 的asset/inline加载
Webpack 构建中 CSS 注入顺序仍错乱？检查这三个点
即使 SCSS 层面完全合规，构建工具仍可能打乱 DOM 中的样式标签顺序：
- 确保只有一个样式入口：
entry: { app: ['./src/index.js', './src/styles/index.scss'] }，避免多个import触发多个<style></style> - 禁用
mini-css-extract-plugin的hmr选项（设为false），热更新时动态追加的<style></style>标签极易插队 - 如果用了
css-modules或scope，确认vue-style-loader或style-loader的injectType配置没启用singleton模式——它会合并所有样式到一个<style></style>，但内部顺序仍取决于模块解析拓扑序
最常被忽略的是：CSS 层叠顺序本质上是“谁最后写入 CSSOM”，而构建工具的 chunk 分割、异步加载、HMR 行为都在悄悄重排这个“最后”。别只盯着 SCSS 文件里的 @use 顺序，得一路跟踪到浏览器 DevTools 的 Elements 面板里，看真实插入的 <style></style> 标签顺序。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
