postcss-loader 必须在 sass-loader 之后运行，否则会因解析 Sass 源码报错；正确顺序为 style-loader → css-loader → postcss-loader → sass-loader；@import 会导致 Dart Sass 退化为 legacy 模式，破坏作用域与嵌套，应改用 @use 并升级至 ≥1.23.0 版本。
postcss-loader 必须在 sass-loader 之后运行，否则它会直接收到 Sass 源码并报错——这不是配置微调问题，是构建链断裂。
Webpack 中 loader 顺序写反了怎么办
Webpack 的 use 数组从右往左执行，常见错误是把 postcss-loader 放在 sass-loader 右侧（即先执行），导致 PostCSS 解析器看到 $color 或 @mixin 就抛 Unknown word。
- 正确顺序必须是：
style-loader→css-loader→postcss-loader→sass-loader - 检查
module.rules中test: /\.scss$/的use数组，确认sass-loader是最后一个 - 用
console.log在自定义 loader 中打点验证执行顺序（临时加一个中间 loader 输出日志） - 若用了
mini-css-extract-plugin，确保其loader配置也遵循同一顺序
为什么 @import 会让整个顺序失效
Dart Sass 遇到任意 @import（包括 @import 'reset.css' 或第三方库里的 @import）就会退化为 legacy 模式：@use 失效、变量作用域混乱、样式被 inline 拼接到文件末尾——PostCSS 收到的是一团结构失控的 CSS，autoprefixer 不加前缀、@nest 静默跳过。
- 全局搜索项目中所有
@import：使用grep -r "@import" src/ --include="*.scss" - 检查
vite.config.ts或vue.config.js中sassOptions.additionalData是否偷偷注入了@import - 升级 Dart Sass 到
≥1.23.0，并彻底卸载node-sass（npm uninstall node-sass） - 用
@use替代@import，入口文件统一用@use "vars" as *;控制作用域
@nest 和 @apply 在 Sass 文件里不生效
@nest 是原生 CSS 嵌套语法，@apply 是 Tailwind 的 PostCSS 插件规则，Sass 编译器根本不认识它们。写在 .scss 里等于无效代码，要么报错，要么被忽略。
-
@nest必须配合postcss-nesting ≥10.0.0，且写法严格：@nest &__title { color: red; }（&必须紧贴@nest后，不能有空格） -
@apply只能在后缀为.css的文件中使用，并确保该文件被完整纳入 PostCSS 流程（即不经过sass-loader） - Vite 用户注意：
postcss.config.js中postcss-nesting必须排在tailwindcss之前，否则 Tailwind 提前重写选择器，@nest被吃掉 - 想保留嵌套写法？改用纯
.css+@tailwindcss/nesting，它不依赖 Sass，但支持类似语法
真正容易被忽略的是：只要有一个 @import 存在，Dart Sass 就强制降级，整个变量、嵌套、命名空间体系就不可控——此时再调 PostCSS 插件，只是对一团乱序 CSS 做无意义加工。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
