Autoprefixer不能写在sass-loader前面，因为它是PostCSS插件，只识别标准CSS语法，无法解析SCSS特有的$变量、@mixin等语法；若顺序颠倒，会报Unknown word或Unexpected token "$"错误。
PostCSS 和 SCSS 必须分两步走：先用 Sass 编译成标准 CSS，再交给 PostCSS 处理；顺序颠倒就会报 Unknown word 或 Unexpected token "$"。
为什么 autoprefixer 不能写在 sass-loader 前面
autoprefixer 是 PostCSS 插件，只认标准 CSS 语法。它看不懂 $color、@mixin 或 @if——这些是 SCSS 专属符号，必须由 sass-loader（或 dart-sass CLI）提前转掉。
- Webpack 中若把
postcss-loader放在sass-loader前，构建时会直接卡住，错误信息里必含Unknown word - Vite 默认满足顺序，但如果你在
vite.config.ts里手动配置了css.postcss.plugins，就得确认它没覆盖掉vite-plugin-sass的前置编译 - 哪怕只用
postcss-preset-env启用 nesting，也得等 SCSS 先展开嵌套，否则它看到的是.btn { &__icon { ... } }这种非法结构
如何让 postcss-scss 解析器正确生效
PostCSS 默认不支持 SCSS 语法，postcss-scss 不是插件，而是解析器（parser），必须显式声明，不能塞进 plugins 对象里。
- 在
postcss.config.js中写parser: 'postcss-scss'，不是plugins: { 'postcss-scss': {} } - 版本要对齐：
postcss@8.4.38搭配postcss-scss@4.0.9；PostCSS 9+ 目前无稳定适配版 -
postcss-scss只对.scss文件生效；.css文件仍走默认解析器，混用时注意后缀别错 - 如果用了 Tailwind，
tailwindcss插件本身不关心语法，但它依赖 AST 已被正确解析，所以 parser 必须最先加载
autoprefixer 和 SCSS @mixin 在兼容性上的分工
autoprefixer 负责动态加/删前缀，@mixin 只适合兜底或特殊场景，比如 backdrop-filter 这类尚未被 autoprefixer 支持的属性。
-
autoprefixer查browserslist配置，按目标浏览器决定是否加-webkit-、删-ms-；@mixin是编译期硬展开，浏览器一升级就可能冗余或漏加 - 不要用
@mixin封装transform、animation等常规属性——autoprefixer 已覆盖完整，自己写反而容易出错 - 真要用
@mixin补前缀，务必加注释说明原因，例如：// fallback for backdrop-filter: not in caniuse yet
常见压缩失败的根源：cssnano 拒绝处理 SCSS 源码
cssnano 只压缩标准 CSS AST，输入若是 .scss 文件，它会直接退出并报错，不会尝试解析。
- 正确链路必须是：
input.scss→dart-sass→output.css→postcss（含cssnano）→dist.css - Webpack 中常见误操作：把
cssnano当作独立 loader 写在sass-loader后，却没确认它是否包裹在postcss-loader内部 - Vite 用户要注意：
css.minify默认启用esbuild压缩，若想用cssnano，得关掉它并在postcss.config.js显式引入
最容易被忽略的一点：所有 PostCSS 插件（包括 autoprefixer、cssnano）都假设输入是“已合法”的 CSS 字符串。一旦你跳过 Sass 编译这步，后续所有优化都会失效，且错误提示往往不指向根本原因——它不会说“你该先跑 sass”，只会报语法异常。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
