Babel 转译和 Polyfill 有什么区别？

简化版

Babel 的语法转换把目标环境无法解析的新语法改写成等价旧语法；Polyfill 则实现环境缺失的运行时 API。箭头函数、可选链主要靠转译，Promise、Map、Array.prototype.includes 等能力缺失要靠 Polyfill，两者必须结合目标浏览器选择。

详细版

Babel 先解析源码得到 AST，再由转换插件改写语法并生成代码。它可以把箭头函数、类、可选链等语法降级，却不会仅凭语法改写就在全局创建 Promise。

Polyfill 是一段运行时代码，它实现规范中的 API，常见来源是 core-js。应用项目可以修改全局环境；可复用库则要谨慎，避免污染使用方的全局对象。

@babel/preset-env 会依据 Browserslist 目标选择语法转换。Babel 7 可用 useBuiltIns 配合 core-js 注入 Polyfill；Babel 8 已移除该选项，应使用专门的 polyfill provider 插件。@babel/plugin-transform-runtime 的重点是复用 Babel helper、隔离部分运行时依赖，并不等于补齐浏览器所有 Web API。

完整版教学

一、先区分解析能力与运行时能力

浏览器执行 JavaScript 要先解析语法，再调用运行时对象。旧引擎如果连 a?.b 都无法解析，代码还没开始运行就会报语法错误；如果能解析 Promise.resolve()，却没有全局 Promise，则会在求值时抛出 ReferenceError。

问题层次	典型例子	常见解决手段
语法无法解析	箭头函数、可选链、类字段	Babel 语法转换
标准内置 API 缺失	`Promise`、`Map`、`includes`	`core-js` 等 Polyfill
Web 平台 API 缺失	`fetch`、`IntersectionObserver`	对应 Web API Polyfill

记忆钩子：转译是“换一种写法表达同一件事”，Polyfill 是“把环境本来没有的零件装进去”。

二、Babel 的转换链路为什么不能创造所有 API

Babel 通常经历“解析源码 → 生成 AST → 插件遍历并改写 AST → 输出代码和 Source Map”。例如箭头函数可改写成普通函数，因为两者都能由旧引擎已有的函数能力表达。

// 输入
const getName = user => user?.profile?.name ?? '匿名'

// 示意输出：真实结果取决于 targets 和插件版本
var getName = function (user) {
  var profile = user == null ? void 0 : user.profile
  return profile == null ? '匿名' : profile.name
}

但 Promise 涉及构造器、状态迁移和微任务调度，不能靠几处 AST 替换完整模拟。语法转换还可能引入 helper；如果每个文件复制一份 helper，包会膨胀，因此才有运行时 helper 复用方案。

三、Polyfill 的注入方式与全局副作用

“入口注入”是在应用入口显式引入所需兼容层；“按使用注入”由工具扫描代码，看到 Promise 或 includes 后加入相应模块。前者容易理解但可能带入更多代码，后者更小，却只能识别静态可见的使用方式。

若某页面只缺 Promise、Map 和 includes，按使用注入可能只带来这 3 组实现；入口导入整个兼容集合则可能包含数十项能力。实际字节数由 core-js 版本、目标环境和压缩器决定，不能脱离构建报告给固定结论。

修改 Array.prototype 或全局 Promise 会影响整个页面，所以应用和库的策略不同。应用掌控运行环境，可以集中注入；公共库应避免擅自改变宿主全局，并把必要运行时要求写进兼容性说明。

四、targets 才是转换结果的真正输入

相同源码面对不同 Browserslist 目标会得到不同产物。若目标都是支持可选链的现代浏览器，保留原语法能减少代码；若还支持旧环境，Babel 才需要降级。

源码 + targets + Babel/插件版本
              ↓
需要的语法转换 + 需要的运行时兼容
              ↓
最终产物体积、可运行环境、调试成本

假设现代包为 120 KB，兼容旧环境后新增 35 KB helper 与 Polyfill，压缩包变成 155 KB，体积增幅约为 (155-120)/120≈29.2%。这说明“多支持一些浏览器”是有下载、解析和维护成本的产品决策。

五、Babel 7、Babel 8 与 transform-runtime 的边界

Babel 7 中常见的是 @babel/preset-env 配置 useBuiltIns: "usage" 或 "entry" 并指定 corejs。Babel 8 已从 preset-env 移除 useBuiltIns，Polyfill 注入应交给 babel-plugin-polyfill-corejs3 等 provider，面试时要先声明版本背景。

@babel/plugin-transform-runtime 会把重复 helper 改为从运行时包导入，并可避免某些全局污染。它不是“浏览器兼容万能包”：DOM、fetch、IntersectionObserver 等 Web API 仍需单独处理。

异步函数也不能机械回答“必需 regenerator-runtime”。具体结果取决于目标环境和转换策略；目标支持原生 async 时可以不转，转换为 generator 状态机时才会涉及相应 helper 或 runtime。

六、用兼容矩阵验证，而不是凭配置猜测

工程上先从用户数据、产品要求或 Baseline 确定目标环境，再查看构建日志和产物，最后在真实目标浏览器或云真机执行测试。仅看到 Babel 配置文件并不能证明兼容，因为第三方依赖、动态代码和 Web API 都可能越过转换链路。

检查项	要回答的问题	验证方式
语法	目标引擎能否解析产物	查看产物并在目标环境启动
内置 API	缺失对象是否已注入	功能测试、兼容矩阵
Web API	`fetch` 等是否存在	真实浏览器测试
体积	是否注入过量兼容代码	Bundle 分析与前后对比

发布时还要固定 Babel、core-js 和 Browserslist 数据版本。否则同一份业务源码在依赖升级后可能产生不同兼容产物，必须由 lockfile、CI 和回归测试共同约束。

七、常见误区与追问

误区：Babel 能解决所有浏览器兼容问题。 它主要处理 JavaScript 语法与指定运行时能力，CSS、DOM 和网络 API 仍有各自的兼容方案。
误区：引入 Polyfill 就一定不会污染全局。 许多 Polyfill 会修改全局构造器或原型，公共库尤其要评估副作用。
误区：async/await 转译后永远需要 regenerator-runtime。 是否需要取决于目标环境、Babel 版本和采用的转换插件。
追问：为什么按使用注入仍可能漏掉兼容项？ 静态扫描无法可靠推断字符串动态访问、运行时拼接和所有第三方代码路径。
追问：preset-env 如何决定转换哪些语法？ 它综合 targets、兼容性数据与已启用插件，选择目标环境缺少的转换。
追问：应用和组件库的 Polyfill 策略为什么不同？ 应用拥有宿主控制权，库却运行在调用方页面，擅自改全局可能产生冲突。
追问：怎样证明兼容配置真的有效？ 用目标浏览器测试、产物分析和自动化回归形成证据，而不是只检查配置名称。

八、加强记忆

把兼容链路记成“先解析、再运行、最后验证”：解析失败找语法转换，运行时对象缺失找 Polyfill，Web 平台能力缺失找专用实现；所有选择都由 targets 驱动。回答时再补上应用与库的全局副作用边界，以及 Babel 7/8 配置差异，就能避免把 Babel、core-js 和 transform-runtime 混成同一种工具。

简化版

详细版