postcss-preset-env 默认不转译 :has() 或 color-mix()，因其处于 stage 3 而非默认 stage 2；需显式设 stage: 3 才启用，但 color-mix() 仍不降级，因无安全 polyfill；真正决定转译行为的是 browserslist 配置，而非 stage 数字。
postcss-preset-env 不是“一键开启所有 CSS 新特性”的开关，它默认只启用 Stage 2 及以上、被主流浏览器广泛支持的特性。所谓“一键”，其实是配置上的一行代码，但背后行为高度依赖目标环境和 stage 级别设定。
为什么 postcss-preset-env 默认不转译 :has() 或 color-mix()
这些特性虽已进入 CSS 规范，但截至 2026 年中，:has() 在 Safari 15.4+ 才稳定支持，color-mix() 仅 Chrome 111+ 和 Firefox 119+ 支持。而 postcss-preset-env 的默认 stage 是 2（对应“草案已被多个实现者确认”），这两个特性目前仍处于 Stage 3 —— 它们不会被自动处理，除非你显式提升 stage 级别：
- 在
postcss.config.js中设stage: 3，否则:has()会被原样保留，导致旧版 Safari 直接忽略整条规则 - 设
stage: 3后，color-mix(blue, red)仍不会降级为渐变或背景图——因为目前没有成熟、无副作用的 polyfill，插件选择跳过转换而非伪造效果 - 部分 Stage 3 特性（如
@container）即使开启 stage 3，也仅添加@supports包裹，不生成回退布局
postcss-preset-env 的 browsers 配置比 stage 更关键
真正决定哪些语法被转译的，不是 stage 数字，而是你声明的浏览器范围。例如：
-
browsers: ['> 0.5%', 'not dead']→ 会启用nesting（CSS 嵌套），因为绝大多数目标浏览器已原生支持；但若你写browsers: ['Chrome 87']，嵌套就会被展开为传统选择器 -
custom-properties（CSS 变量）在 IE 完全不支持，所以只要目标含 IE11，--color就会被替换为color值，并注入:root回退声明 - 误配
browsers会导致“本该转译的没转”（如漏掉and_chr 112）或“不该转的强行转”（如对 Chrome 120+ 还展开嵌套，徒增体积）
和 precss 混用会破坏 postcss-preset-env 的语义推断
precss 提供 $var 变量、&-mod 嵌套等 Sass 风语法，但它和 postcss-preset-env 的设计目标冲突：
-
precss的嵌套是预处理器式展开，postcss-preset-env的嵌套是标准 CSS 嵌套（nav { ul { ... } }），两者共存时 AST 解析易出错，常见报错：Cannot read property 'type' of undefined -
precss的$primary变量在postcss-preset-env看来是非法 token，会导致自定义属性（--primary）的值无法被正确提取和回退 - 如果你需要 Sass 风语法，应二选一：用
precss+ 手动补兼容性；或坚持标准 CSS 语法，只用postcss-preset-env处理真实规范特性
真正“必备”的地方：它让 /* autoprefixer */ 注释失效
很多人以为 postcss-preset-env 是 autoprefixer 的替代品，其实它是超集——它内部已集成 autoprefixer，且优先级更高。这意味着：
- 你在 CSS 里写
/* autoprefixer: off */对postcss-preset-env无效；它仍会对display: flex加-webkit-前缀（如果目标浏览器需要） - 想局部禁用前缀，得改用
postcss-preset-env的语法：/* postcss-preset-env: off */ - 若同时配置了独立的
autoprefixer插件，会出现重复加前缀、甚至互相覆盖的问题，构建产物体积增大 10%~15%
真正容易被忽略的点是：它不处理运行时逻辑，也不模拟缺失的渲染行为。比如 aspect-ratio 在不支持的浏览器里不会“假装有宽高比”，只是被忽略——你需要自己加 JS fallback 或媒体查询兜底。工具再智能，也无法绕过浏览器渲染引擎的硬限制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
