PostCSS原生嵌套（@nest）与postcss-nested插件不能共存，因解析逻辑冲突导致报错或CSS结构扁平化；需删除postcss-nested、确保PostCSS≥8.4.0、使用标准@nest语法且&必须位于选择器开头。
PostCSS 原生嵌套（@nest）和旧版 postcss-nested 不能共存
PostCSS 官方在 v8.4+ 中原生支持 CSS 嵌套语法（基于 @nest 规则），但旧插件 postcss-nested 使用的是非标准的、类 Sass 的缩进式写法（如直接缩进子选择器）。两者解析逻辑冲突：一个按规范走 @nest 显式声明，另一个尝试隐式推导嵌套关系。只要两者同时加载，postcss-nested 就会提前消费嵌套结构，导致原生解析器收不到原始嵌套节点，报错或生成错误 CSS。
常见错误现象包括：
-
Unknown word或Unexpected token出现在@nest行 - 嵌套规则被忽略，子选择器变成顶层样式
- 构建时无报错但输出 CSS 结构扁平化
如何确认你正在用原生嵌套而非 postcss-nested
检查你的 postcss.config.js 或构建配置中是否显式引入了 postcss-nested —— 如果有，必须删掉。PostCSS v8.4+ 后，原生嵌套是内置能力，无需额外插件，只需确保：
- PostCSS 版本 ≥
8.4.0（建议 ≥8.4.31以避开早期@nest解析 bug） - 未在插件数组中写入
require('postcss-nested')或类似引用 - 使用的是标准语法：
@nest &:hover { ... }，而不是缩进写法
若你依赖 Webpack/Vite，还要注意它们自带的 PostCSS 版本是否被锁定 —— 比如 Vite 4.x 默认带 postcss@8.4.21，够用；但某些旧版 vue-cli 可能锁在 8.3.x，此时 @nest 直接不识别，报 Unknown at rule @nest。
立即学习“前端免费学习笔记（深入）”；
@nest 的语法限制比预想中更严格
原生嵌套不是“把 Sass 写法搬过来”，它只允许在 @nest 规则内使用 & 引用父选择器，且 & 必须出现在选择器开头（或紧跟逗号后），不支持 &.mod 以外的任意位置拼接。例如：
@nest &:hover { color: red; }
@nest &.active { display: block; }
@nest & + li { margin-top: 0; }
以下写法会失败：
-
@nest li & { ... }（&不在开头） -
@nest .parent & { ... }（&前有其他选择器） - 省略
@nest直接缩进（会被当作无效 CSS 报错）
这和 postcss-nested 的宽松解析完全不同，迁移时需逐条重写嵌套块。
兼容性与构建工具链的隐性干扰
即使配置正确，某些工具仍可能绕过你的 postcss.config.js。比如：
- Vite 的
css.preprocessorOptions不影响 PostCSS 配置，但若你同时启用了css.modules，模块化作用域可能和&解析产生意外交互 - Next.js 13+ 的 App Router 默认启用 CSS Modules，且内部 PostCSS 加载顺序不可控，容易覆盖你的配置
- Webpack 的
postcss-loader若版本太老（如6.x），可能无法传递新版 PostCSS 的嵌套 AST 节点
最稳妥的验证方式：临时删掉所有其他 PostCSS 插件，只留 postcss-preset-env（可选）和原生解析，跑一次 postcss input.css -o output.css 命令行直出，看输出是否符合预期 —— 这能快速排除构建封装层的干扰。
真正麻烦的从来不是语法本身，而是你根本没意识到某个依赖悄悄注入了 postcss-nested，或者 CI 环境里 Node 版本触发了 PostCSS 的 polyfill 分支，让 @nest 解析器压根没加载。
