postcss-preset-env仅在目标浏览器不支持、特性有静态降级路径且显式启用时才转译；@container默认被忽略，需features: {'container-queries': true}启用，且依赖浏览器原生支持或js polyfill。
postcss-preset-env 不是“开了就能用新语法”的开关，它只在满足三个条件时才真正转译：目标浏览器不支持、特性有静态降级路径、且你显式允许。缺一不可。
为什么写了 @container 却完全没效果
因为 @container 默认被忽略——它没有 CSS 级 fallback 方案，postcss-preset-env 不会把它编译成媒体查询或 JS 检测逻辑。
- 必须在插件配置中显式启用：
features: { 'container-queries': true } - 即使启用了，也仅保证语法解析通过；运行时仍依赖浏览器原生支持（Safari 15.4+ 有部分支持但
container-type: inline-size行为不一致） - 真要兼容老浏览器，得额外引入
@csstools/container-query-polyfill并在 JS 中注册，postcss-preset-env不负责这事 - 别指望 stage 值能自动打开它：stage 是准入门槛，不是功能列表，
container-queries属于 Stage 3，但 stage: 3 本身不等于“全开 Stage 3”
stage 参数到底控制什么
stage 决定哪些特性“有资格参与转译判断”，但它不是功能开关，也不影响最终是否输出代码。
-
stage: 0：尝试解析@property等实验语法，多数无 polyfill，容易报错或静默失效 -
stage: 2：覆盖嵌套规则、逻辑属性等，适合尝鲜，但部分 polyfill（如custom-media-queries）在旧浏览器中行为不稳定 -
stage: 3：最常用，nesting-rules、custom-properties、inset等基本稳，polyfill 较成熟 -
stage: 4：仅含已发布标准，反而排除color-mix()（它仍是 Stage 3），实际启用特性极少 - 设
stage: 4却发现color-mix()没 fallback？正常——它被阶段门槛直接过滤掉了
为什么 browserslist 配置比 stage 还关键
postcss-preset-env 的所有转译决策都基于 browserslist 推导“哪些浏览器不支持”。没它，插件根本不知道要不要动你的 :has() 或 aspect-ratio。
- 必须在项目根目录加
.browserslistrc，内容类似：> 1%last 2 versionsnot deadie 11 - 或者写在
package.json里："browserslist": ["> 1%", "last 2 versions", "ie 11"] - 常见错误：写了
stage: 3，但browserslist没配ie 11，结果display: grid完全没变——插件认为“没问题”，自然不转译 - Chrome 88–92 对
aspect-ratio有渲染 bug，但postcss-preset-env不管 bug，只按 Can I Use 标准支持表决定是否转译
color-mix() 和类似函数为什么没 fallback
这类函数属于“必须原生支持”的特性，没有等价的静态 CSS 替代方案。postcss-preset-env 不会为你生成 background: #000 这类 fallback，那是你自己的事。
- 即使开启
features: { 'color-function': true }，也只是让语法合法，不改变运行时行为 - Chrome 111+ 直接保留
color-mix()，旧版浏览器看到就忽略 - 想兼容，得手动写两行：
background: #000;再写background: color-mix(...); - 类似情况还有
relative-color-syntax、font-palette等，它们都依赖运行时环境，不是构建时能解决的
postcss-preset-env 只处理「能静态降级」的部分（比如把 gap 转成 margin），而像 @container、color-mix() 这类，它只负责让你写得合法，剩下的兼容性得靠你自己补全——要么靠浏览器，要么靠 JS polyfill，要么靠手写 fallback。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
