postcss-preset-env 必须协同 browserslist、stage 和 features 三者配置才生效；stage 是特性准入门槛而非开关，仅筛选符合成熟度标准的特性，实际转译由 browserslist 目标和 features 显式启用共同决定。
直接说结论：postcss-preset-env 不是“开个开关就能用新 CSS”，它必须和 browserslist 配合、按标准成熟度（stage）筛选、再由 features 显式启用，三者缺一不可；单独设 stage: 2 或只写 features: { 'nesting-rules': true } 都可能不生效。
为什么 stage 参数不是功能开关
stage 是特性准入门槛，不是启用列表。设 stage: 3 表示“只考虑已进入 W3C 候选推荐（CR）阶段的特性”，比如 nesting-rules 和 custom-properties 符合，但 color-mix() 当前仍是 Stage 3，而 container-query 虽在 Stage 3 却依赖 JS 运行时检测，postcss-preset-env 不处理——它只做静态编译。
常见误判：
- 写了
stage: 4却发现color-mix()没转译？因为该函数还没到 Stage 4，被直接过滤了 - 设了
stage: 0就以为能用@property？语法可能解析过去，但无 polyfill，实际运行无效 - 没配
browserslist，stage判断会失准，插件退回到默认目标（如last 2 versions），但降级逻辑不可控
怎样正确配置 browserslist + stage + features
三者必须共存，顺序不能乱：先由 browserslist 定义目标环境，再由 stage 筛出“有资格参与编译”的特性，最后靠 features 显式打开其中一部分。
实操建议：
- 在项目根目录加
.browserslistrc，内容例如：last 2 versions > 1% not dead
-
postcss.config.js中必须同时声明stage和features，不能只写一个：require('postcss-preset-env')({ stage: 3, features: { 'nesting-rules': true, 'custom-properties': { preserve: false }, 'logical-properties-and-values': true } }) - 想启用一个 stage 未覆盖的特性（如 Stage 2 的
font-variant-property），只能靠features强制加，但要确认它在 cssdb.org 标记为「可 polyfill」，否则只是语法通过、无实际输出
嵌套规则（nesting-rules）和自定义属性（custom-properties）的典型陷阱
这两个最常用，但行为常被误解：
-
nesting-rules: true后，& .child { color: red; }会被展开为.parent .child { color: red; }，但&:hover不会提升选择器权重——它仍是原始语义，别指望靠嵌套解决 specificity 问题 -
custom-properties: { preserve: false }表示不保留原始变量声明，全部内联降级；若设为true（默认），旧浏览器看到的是未解析的var(--color)，必须配合 JS polyfill 才能生效 -
nesting-rules不支持跨选择器引用，比如& + &或&.active &在部分版本中不识别，需查插件文档对应版本支持表
最容易被忽略的一点：所有转译结果都取决于 browserslist 实际覆盖的浏览器能力。哪怕你启用了 color-mix()，如果目标浏览器（如 Chrome 115）原生支持，它就不会被降级；反之，若目标含 Safari 15.6，而该函数尚未支持，才会生成 fallback。别把 stage 当兼容性开关，它只管“能不能进候选池”，不管“要不要真干活”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
