PostCSS不能放在sass-loader前面，因为PostCSS解析器只识别标准CSS语法，不支持$color、@mixin等Sass特性，否则会报Unknown word或Unexpected token "$"错误；Webpack中loader从右到左执行，故sass-loader必须在postcss-loader右侧以确保先编译后处理。
PostCSS 和 Sass 必须分两步执行：Sass 先编译成标准 CSS，PostCSS 再处理这串合法 CSS。顺序颠倒或混用会导致 Unknown word、Unexpected token "$" 这类解析错误。
为什么 postcss-loader 不能放在 sass-loader 前面？
PostCSS 解析器只认标准 CSS 语法，不支持 $color、@mixin、@if 等 Sass 特性。一旦 postcss-loader 先运行，它会直接报错退出。
- Webpack 中 loader 执行顺序是从右到左，所以
sass-loader必须在postcss-loader右侧（即先执行） - Vite 默认满足该顺序，但若手动配置
vite-plugin-sass，需确认其enforce: 'pre'未被覆盖 - Gatsby 必须通过
gatsby-plugin-sass注册，否则import "./style.scss"会触发Module parse failed: Unexpected character '@'
如何让 autoprefixer 和 cssnano 正确作用于 Sass 输出？
autoprefixer 和 cssnano 都只工作在标准 CSS AST 上，它们对 .scss 文件完全无效。必须确保输入是 Sass 编译后的 .css 字符串。
- Webpack 示例中，
.scss规则的use数组应为：['style-loader', 'css-loader', 'postcss-loader', 'sass-loader']（注意顺序） -
postcss.config.js中插件列表只需写require('autoprefixer')和require('cssnano')，无需关心 Sass 源码结构 -
cssnano默认丢弃 sourceMap，如需保留调试链，得显式配置：{ preset: ['default', { discardComments: { removeAll: true } }] }并确保所有 loader 的sourceMap: true开启
开发时如何避免压缩破坏可读性与调试体验？
压缩和清理类操作（如 cssnano、postcss-discard-empty）应在生产环境启用，开发阶段应禁用或降级。
立即学习“前端免费学习笔记（深入）”；
- 用
process.env.NODE_ENV === 'production'控制插件加载，例如：process.env.NODE_ENV === 'production' && require('cssnano') - 开发时保留空行、注释和缩进，否则 DevTools 中点击样式跳转源文件会失败
- 若使用
postcss-preset-env，它的stage参数影响语法降级强度，开发建议设stage: 3，生产可设stage: 2加强兼容性
最容易被忽略的是 sourceMap 链断裂——Sass 编译、PostCSS 处理、cssnano 压缩三步都得透传且不覆盖 map，否则你永远点不到原始 .scss 行号。
