首先得明确一个核心点：babel-preset-env本身是一个编译时工具，它不会在代码运行时检测实际的环境版本。下面我会拆解它的逻辑，以及遇到「编译目标和实际运行环境不匹配」时的解决办法。

一、babel-preset-env的核心工作逻辑 #

当你在编译时指定目标环境（比如targets: { safari: "10" }），babel-preset-env会做这些事：

• 基于兼容性数据库，静态分析目标环境（Safari 10）支持哪些ES语法和API
• 只对目标环境不支持的语法做转译，只注入目标环境缺失的polyfill
• 编译输出的代码是固定的，完全基于你编译时的配置，不会根据实际运行的环境动态调整

举个例子：Safari 10支持Array.prototype.includes，但Safari 9不支持。如果你编译时指定目标是Safari 10，babel-preset-env就不会给你注入includes的polyfill——哪怕你的代码最终跑到了Safari 9里，也不会有额外的逻辑来补这个polyfill，这时候就会出现运行时错误。

二、针对「运行环境比编译目标旧」的典型解决方式 #

既然babel-preset-env不做运行时检测，我们就得靠其他手段来覆盖这类场景，这里列出几个常用方案：

1. 配置更保守的targets（最稳妥） #

直接把编译目标设为你需要支持的最低版本。比如你需要兼容Safari 9及以上，那就在配置里写targets: { safari: "9" }。这样babel-preset-env会直接把所有Safari 9缺失的特性都做转译和polyfill，不管代码最终跑在哪个版本的Safari里，都能正常运行。

这种方式的缺点是，对于新版本浏览器来说，代码会包含一些不必要的polyfill和转译逻辑，体积会稍大，但胜在简单可靠。

2. 运行时检测+动态加载polyfill #

如果你想兼顾旧环境兼容性和新环境的代码体积，可以在运行时先检测当前环境缺失哪些特性，再动态加载对应的polyfill。

比如手动做特性检测：

// 检测Array.includes是否存在
if (!Array.prototype.includes) {
  // 动态加载对应的polyfill
  import('core-js/es/array/includes');
}

你也可以利用专门的工具来批量做这件事：这类工具会根据当前环境的特性支持情况，自动加载所需的polyfill集合，确保只加载当前环境真正需要的内容。

3. 配合@babel/plugin-transform-runtime和core-js #

使用@babel/plugin-transform-runtime可以避免polyfill污染全局环境，同时结合core-js@3的按需加载能力，让polyfill的注入更精准。不过这种方式仍然是基于编译时的targets配置，所以如果要覆盖更旧的环境，还是需要配合运行时检测来补充。

4. 按环境拆分编译产物（进阶方案） #

用webpack之类的构建工具做代码分割，编译出多份针对不同环境的代码包。然后在入口文件里先检测当前运行环境，再加载对应版本的代码。

比如：

// 入口文件
if (isSafariVersionLessThan(10)) {
  import('./legacy-safari-bundle.js');
} else {
  import('./modern-bundle.js');
}

这种方式能最大化优化不同环境下的代码体积，但实现起来需要额外的配置和环境检测逻辑，适合对性能要求极高的项目。

最后补充 #

babel-preset-env之所以不内置运行时检测，是因为它的设计定位是「编译时优化工具」——大部分场景下，开发者是明确知道自己需要支持的最低环境版本的，静态配置已经能满足需求。运行时检测会增加代码的复杂度和额外的运行时开销，所以交给开发者根据自己的场景来选择是否需要。

内容的提问来源于stack exchange，提问作者doberkofler