原生CSS嵌套语法（@nest）仅Chrome 125+、Safari 17.4+、Firefox 127+支持，PostCSS无法降级为等效扁平选择器，必须二选一使用postcss-nesting或postcss-nested插件，且二者互斥。
原生CSS嵌套语法（@nest）目前仅在 Chrome 125+、Safari 17.4+、Firefox 127+ 中原生支持，IE 和绝大多数旧版浏览器完全不识别。PostCSS 无法“降级”嵌套结构为等效的扁平选择器——它只能展开或报错，不能智能生成语义等价的 CSS。所以，所谓“向下兼容”，本质是：选对插件 + 明确编译目标 + 接受展开后选择器权重变化。
必须二选一：postcss-nesting 还是 postcss-nested？
这两个插件处理的是完全不同的语法，且互斥：
- 要写
.card { @nest & .title { color: blue; } }→ 必须用postcss-nesting（W3C 原生提案实现） - 要写
.card { .title { color: blue; } }（Sass 风格）→ 必须用postcss-nested - 同时装两者会导致
TypeError: Cannot read property 'type' of undefined或静默跳过嵌套规则 -
npm ls postcss-nesting postcss-nested确认只存在一个；删掉另一个再重装
postcss-nesting 的最小可用配置
它不依赖 postcss-preset-env，也不能和后者共存（尤其不能开启 nesting: true）：
- 安装：
npm install --save-dev postcss-nesting -
postcss.config.js中只写这一行插件：require('postcss-nesting') - 删掉
postcss-preset-env配置里的nesting-rules: true或整个features.nesting-rules字段 - 确保 PostCSS 版本 ≥ 8.4（
npm ls postcss检查）
展开后的选择器权重和维护风险
插件会把嵌套结构机械展开，例如：
立即学习“前端免费学习笔记（深入）”；
.card {
@nest & .title { color: blue; }
@nest &:hover > .content { font-weight: bold; }
}
→ 编译为：
.card .title { color: blue; }
.card:hover > .content { font-weight: bold; }
- 展开后选择器层级变深，可能意外覆盖其他组件样式（比如
.card .title比.title权重高） - 无法还原父选择器的动态状态（如
&[data-mode="dark"]展开后仍是静态字符串） - 如果项目已用 BEM，嵌套写法反而容易破坏命名约束，建议团队提前约定是否允许混合使用
为什么不用 postcss-preset-env 开启 nesting？
它底层调用的正是 postcss-nesting，但封装层会引入额外判断逻辑：
- 若
stage ，即使写了 <code>@nest也会被忽略（不报错、不展开） - 若
targets里没包含支持嵌套的浏览器（如漏掉safari: '17.4'），插件可能跳过处理 - 更关键的是：
postcss-preset-env默认启用 autoprefixer，而它的 autoprefixer 和独立autoprefixer插件共存会冲突，必须显式关掉内置前缀器：autoprefixer: false
直接用 postcss-nesting 更轻量、行为更可预测——只要语法合法，就一定展开，不看 targets，也不猜 stage。
