Babel 是怎么把新语法转成旧语法的？为什么还需要 Polyfill？

知识点详解：编译时的改写，和运行时的能力补充

Babel 并不是拿字符串做简单替换

咱们假设源码包含箭头函数。解析器会先把代码变成抽象语法树，也就是 AST。树里记录函数、参数、表达式等结构，转换插件再按照结构修改，生成器输出新的代码。

因此，转换工具能够识别“这是一个函数”，而不是看到 => 就随意替换字符。关于目标环境与插件选择，可以查Babel preset-env 文档。

不过，不要据此承诺“所有新语法都能被无损转换”。转换支持、目标限制和插件选项仍然要逐项核对。例如某些转换依赖辅助函数；某些新能力根本不是语法问题。

Promise 是一个对象能力，不是一个标点

假设旧环境能够解析转换后的代码，但执行到 new Promise(...) 时，环境里没有 Promise。此时仍会报错。

Babel 可以改写代码的写法，却不会因为代码里出现了一个名字，就让环境自动拥有对应实现。Polyfill 的工作，是在可实现的范围内提供缺失的运行时能力。

这里还要区分两个容易混淆的概念：Babel 的辅助代码是为了支持转换后的代码；Polyfill 则补充目标环境缺失的 API。两者可能一起出现，但解决的问题不同。

preset-env 怎样决定要做什么

preset-env 会根据目标环境和相关支持数据，决定需要哪些转换。使用 Polyfill 相关选项时，还需要明确 core-js 等依赖及配置。

如果设置为按使用注入，工具会分析代码里用到了什么，再按目标环境补入相应内容；入口式注入则从指定入口出发处理。具体行为要按当前配置核对，不能把“按使用”理解成对所有运行时动态访问都能精确识别。

Babel 关于旧 babel-polyfill 的说明已经将它标为弃用方向，所以新项目不能直接照抄多年以前的安装方式。采用什么补充方案，应结合当前工具链和目标浏览器确认。

应用和库，补充方式可能不同

普通应用可以控制自己的运行环境，按需要补入全局 API。组件库被很多应用引用，如果随意改动全局对象，就可能产生冲突。

因此，库开发要额外考虑是否采用不污染全局的方案，以及消费者负责什么兼容要求。某些 Babel runtime 方案帮助复用辅助函数，也有对应运行时方案，但不能仅凭名字推导出“所有 API 都已兼容”。

可以从一个具体问题检查配置：目标浏览器不支持某个语法、也不支持某个 API。查看输出代码，确认语法是否转换；查看加载内容，确认 API 由谁提供；最后在目标环境运行。

只看现代浏览器里页面正常，不能证明旧浏览器兼容。开发机器本来就有这些能力，它可能把缺少的配置掩盖掉。

面试官继续追问

为什么转译后还可能出现语法错误？

可能是目标配置不完整、依赖没有经过需要的处理，或该转换未启用。先确定报错代码来自哪里，再检查构建输出，不能直接断定 Babel 没有生效。

Fetch 能像 Promise 一样处理吗？

要看采用的补充实现及其能力范围。API 属于什么环境、能否模拟，都需单独检查；不能认为 core-js 包含所有浏览器 API。

支持现代浏览器还需要 Polyfill 吗？

取决于目标环境与实际使用的能力。支持范围足够时可以不需要某些补充。减少不必要的兼容代码，也能降低下载和执行成本。

面试速记卡

• Babel：解析、转换 AST，再生成代码。
• 语法转换：改变代码写法以适配目标环境。
• Polyfill：在可实现范围内补充缺失的运行时 API。
• 配置重点：目标环境、转换选项和补充依赖都要核对。
• 验证方式：看构建产物，再在真实目标环境运行。