PostCSS Preset Env 是标准 CSS 未来特性的兼容性转换工具，非语法糖编译器；它依据规范阶段（stage 0–4）和目标浏览器（targets）自动降级新特性，不处理已广泛支持的稳定语法，也不注入运行时 polyfill。
PostCSS Preset Env 本身不“编写” CSS，它只负责把现代 CSS 语法（比如 color-mix()、:has()、nest）按目标浏览器支持情况，自动转译成兼容性更强的等价写法。你照常写原生 CSS，它在构建时默默处理降级。
为什么 postcss-preset-env 不是语法糖编译器
它不是像 Sass 那样提供新语法（如 @mixin），而是聚焦于标准 CSS 的未来特性落地。能否启用某项功能，取决于两件事：你写的语法是否已进入 CSS 规范草案阶段，以及你配置的 browsers 或 targets 是否需要降级。
- 例如写
display: grid不会触发任何转换——它已是广泛支持的稳定特性 - 但写
background-color: color-mix(in srgb, red 50%, blue)会被转成background-color: #800080（静态计算）或 fallback 声明（取决于配置） -
nest语法（如& .child { }）默认不开启，需显式设置stage: 3或更高
如何配置 stage 和 features 控制转换粒度
stage 是核心开关：它按 CSS 标准推进流程（Stage 0–4）批量启用特性；features 则允许单独开关某个特性，优先级更高。
-
stage: 2启用已进入“推荐草案”的特性（如logical properties、custom media queries） -
stage: 3加入更激进的提案（如nest、container queries，但注意部分需额外 polyfill） - 想只开
nest而不开container？直接写：features: { 'nesting-rules': true } - 想关掉某项默认启用的特性？设为
false：features: { 'custom-properties': false }
常见误配：把 stage 设成 4 却没意识到 Stage 4 = 已发布标准，此时 preset-env 实际不作任何转换——它只处理“未完全普及”的特性。
立即学习“前端免费学习笔记（深入）”；
目标环境配置必须用 targets，别依赖 .browserslistrc
PostCSS Preset Env 从 v7 开始**默认忽略 .browserslistrc**，只认 targets 字段。如果你没显式声明，它会按“全球平均支持率”回退，结果不可控。
- 正确写法（在
postcss.config.js中）：module.exports = { plugins: { 'postcss-preset-env': { targets: { chrome: '100', safari: '15.4', edge: '105' } } } } - 错误写法：只放
.browserslistrc文件却不传targets，结果:has()可能被保留（因 Safari 15.4+ 已原生支持），也可能被剔除（若 preset-env 误判目标环境） - CI/CD 中尤其要注意：Node 环境下
targets必须硬编码或通过环境变量注入，不能指望读取项目根目录的配置文件
遇到 Unknown word 错误，先检查插件顺序和嵌套语法
这个错误通常不是语法写错，而是 PostCSS 插件链中 postcss-preset-env 的位置太靠后，导致其他插件（如 postcss-nested）已提前报错。
- 确保
postcss-preset-env在postcss-nested、postcss-custom-properties等同类插件**之前**执行 - 如果你手动启用了
nesting-rules，就不要再额外装postcss-nested——二者冲突，后者会把& .child当未知语法抛错 - 检查是否误用了非标准缩写：例如写
gap: 1rem 2rem;没问题，但gap: 1rem / 2rem;（斜杠分隔）是实验性语法，需stage: 3且明确开启'explicit-cross-axis-gap'
真正麻烦的是那些需要运行时 polyfill 的特性（如 :has() 在旧版 Chrome），preset-env 不负责注入 JS 补丁——它只做 CSS 层转换，这点很容易被忽略。
