PostCSS插件无法处理Sass变量，仅作用于编译后的CSS；需确保Sass先输出标准CSS（如用--前缀定义变量），再由PostCSS处理原生特性（如@nest、自定义属性），且postcss-nesting必须v10+、置于插件首位、&紧贴@nest后。
PostCSS插件在Sass编译后才运行，变量和嵌套根本没机会处理
PostCSS对Sass变量（如$color-primary）完全无感——它只处理最终生成的CSS。Sass编译完，$color-primary早已被替换成#007bff，PostCSS看到的只是普通CSS文本，不可能再“降级”或“转义”这些值。
真正需要PostCSS处理的，是原生CSS特性：比如--color: #007bff变量、@nest规则、lighten()函数（需postcss-color-function）等。如果你指望PostCSS把Sass变量转成兼容写法，那从起点就错了。
- 确保所有CSS变量用
--前缀定义，并在:root或作用域内显式声明 - Sass逻辑层只负责计算和拼接，例如：
$primary: #007bff; :root { --primary: #{$primary}; } - PostCSS插件（如
postcss-custom-properties）必须放在postcss-preset-env之前，否则会被后者覆盖
loader链顺序颠倒导致Sass输出被跳过或损坏
Webpack里css-loader必须在sass-loader之后、style-loader之前。常见错误是把sass-loader配在css-loader后面，结果Sass代码直接被当成纯CSS传给css-loader，@use、@mixin全报错。
- 正确顺序：
style-loader→css-loader→postcss-loader→sass-loader -
postcss-loader必须紧挨css-loader之后，否则PostCSS收不到Sass编译后的CSS - Vite用户注意：
css.postcss.plugins数组里，postcss-nesting要放在tailwindcss之前，否则Tailwind会提前重写选择器，@nest失效
混用@import和@use让整个Sass模块系统崩溃
只要文件里存在任意一处@import（哪怕只有一行@import "reset";），Dart Sass立刻退化为legacy模式：所有@use被忽略、命名空间消失、样式强制inline到文件末尾——PostCSS拿到的是一团乱序拼接的CSS，顺序和结构全不可控。
立即学习“前端免费学习笔记（深入）”；
- 全局搜索项目中所有
@import，包括node_modules里的第三方库（如旧版Bootstrap） - 检查构建配置：
vite.config.ts或vue.config.js中sassOptions.additionalData是否偷偷注入了@import - 确认
sass版本≥1.23.0：npx sass --version；node-sass已废弃，不支持@use
postcss-nesting配置错位或版本过低，@nest静默失效
postcss-nesting v10+才严格遵循CSS Nesting草案，且要求&必须紧贴@nest后最左侧，不能有空格。v9及更早版本或postcss-nested（名字只差一个字母）会把嵌套当Sass语法处理，产出错误选择器。
- 运行
npm list postcss-nesting，若版本≤9.x，执行npm uninstall postcss-nested && npm install postcss-nesting@latest - 确保
postcss-nesting在postcss.config.js的plugins数组最前面 - 写法必须是：
@nest &:hover { color: red; }，而不是@nest & :hover（中间空格即失效）
真正的关键不在“怎么配”，而在“谁先看到原始语法”：Sass不能吃掉@nest，PostCSS必须在任何选择器重写插件之前拿到它。顺序和版本，漏一个，嵌套就白写。
