动态导入与异步函数的Babel转译配置实战

Babel实战：让现代JavaScript在老旧浏览器中优雅运行

你有没有遇到过这样的场景？本地开发一切正常，页面加载飞快，异步逻辑清晰简洁。可一发布到线上，用户那边却报错：“regeneratorRuntime is not defined” 或者 “import is not a function”。刷新页面的瞬间，心里咯噔一下——又是一个兼容性问题。

别急，这并不是代码写错了，而是现代 JavaScript 语法与老旧运行环境之间的“代沟”。尤其是当你用上了async/await和动态导入import()这些利器时，这种冲突尤为明显。

今天我们就来彻底搞懂：如何通过 Babel 配置，让你写的现代 JS 能在 IE11、老版本安卓浏览器甚至某些 Node.js 环境中稳定运行。

为什么需要转译？从一个真实错误说起

设想你在做一个后台管理系统，为了优化首屏性能，你对非核心模块做了懒加载：

const loadReport = async () => { const { renderChart } = await import('./charts.js'); renderChart(data); };

逻辑很清晰：点击按钮才加载图表组件。但在 IE11 中，这段代码直接抛出异常：

Object doesn't support property or method 'import'

更离谱的是另一个错误：

regeneratorRuntime is not defined

这两个错误，分别指向了两个关键特性：动态导入和异步函数的缺失支持。

解决它们，不是靠祈祷用户升级浏览器，而是靠构建工具链的正确配置。而这一切的核心，就是@babel/preset-env。

@babel/preset-env：智能转译的“大脑”

过去我们可能会手动引入一堆插件，比如transform-es2015-modules-commonjs、syntax-async-functions……但这种方式维护成本高，且容易遗漏。

现在，官方推荐使用@babel/preset-env—— 它就像一个智能决策系统，能根据你的目标环境自动判断哪些语法需要转译。

它是怎么“知道”的？

preset-env背后依赖两大数据库：
- browserslist ：定义目标浏览器范围；
- compat-table ：记录各浏览器对 ES 特性的支持情况。

举个例子：

{ "presets": [ [ "@babel/preset-env", { "targets": { "browsers": ["last 2 versions", "ie >= 11"] } } ] ] }

当你写下这个配置，Babel 就会去查：Chrome 最新两个版本和 IE11 是否都支持async/await？是否支持import()？如果不支持，就自动启用对应的转译插件。

这就避免了“一刀切”式的全量降级，也防止了“漏网之鱼”导致的运行时崩溃。

动态导入import()到底怎么处理？

import('./module')看似只是一个函数调用，但它其实是ES2020 正式标准的一部分，底层涉及模块解析、网络请求、执行上下文管理等复杂机制。

关键点：Babel 不负责加载，只负责语法转换

很多人误以为 Babel 会把import()转成require.ensure或System.import。其实不然。

Babel 只做一件事：确保import()语法能被解析为合法的函数调用形式。

例如：

const module = await import('./lazy.js');

会被转译为类似：

const module = await _import('./lazy.js');

这里的_import并不是 Babel 提供的，而是由打包工具（如 Webpack）注入的运行时函数。如果你没有使用 bundler，那这个_import就不存在，自然报错。

🔥 所以，“import is not a function” 的根本原因，往往是：你用了动态导入语法，但运行环境既不原生支持，也没有打包工具提供 polyfill。

如何正确配置？

场景一：配合 Webpack 使用（最常见）

设置"modules": false，让 Webpack 自己处理模块系统：

{ "presets": [ [ "@babel/preset-env", { "targets": { "ie": "11" }, "modules": false } ] ] }

这样 Babel 会保留 ES Module 语法（包括import()），交由 Webpack 进行代码分割和 chunk 生成。

场景二：纯脚本环境（无 bundler）

你需要引入一个运行时 shim，比如systemjs或自定义 loader。不过这种情况较少见，通常出现在微前端或 legacy 嵌入式脚本中。

💡 小知识：Chrome 63+ 才开始原生支持动态导入。你可以用命令验证：

bash npx browserslist "not chrome >= 63"

如果你的目标包含低于此版本的浏览器，就必须依赖打包工具来实现加载逻辑。

async/await转译背后的黑科技：Regenerator

相比动态导入，async/await的转译更为复杂。因为它不仅仅是语法替换，还涉及到控制流的重写。

它的本质是什么？

async/await是基于生成器（Generator）和 Promise 构建的语法糖。Babel 使用 Facebook 开发的Regenerator 编译器，将async函数转换为一个状态机。

来看一个简化版的转换过程：

源码：

async function fetchUser(id) { const res = await fetch(`/api/users/${id}`); const user = await res.json(); return user.name; }

Babel 转译后（抽象示意）：

function fetchUser(id) { return _asyncToGenerator(function* () { const res = yield fetch(`/api/users/${id}`); const user = yield res.json(); return user.name; })(); }

中间那个_asyncToGenerator是关键辅助函数，它把 generator 包装成 Promise，并模拟await的暂停与恢复行为。

而这个yield能够工作的前提，是全局存在regeneratorRuntime对象。

“regeneratorRuntime is not defined” 怎么破？

这是最常见的运行时错误之一。根源在于：虽然 Babel 生成了_asyncToGenerator调用，但regenerator-runtime没有被加载。

解法一：手动引入 runtime（适合小型项目）

安装依赖：

npm install regenerator-runtime

在项目入口文件顶部加入：

import 'regenerator-runtime/runtime';

这会挂载global.regeneratorRuntime，所有转译后的 async 函数都能找到它。

解法二：让preset-env自动注入（推荐！）

更聪明的做法是利用@babel/preset-env的useBuiltIns功能，按需注入 polyfill。

配置如下：

{ "presets": [ [ "@babel/preset-env", { "targets": { "firefox": "60" }, "useBuiltIns": "usage", "corejs": { "version": 3, "proposals": true } } ] ] }

解释几个关键参数：

有了这套配置，只要你在某个文件里用了async/await，Babel 就会在该文件开头自动插入：

require("regenerator-runtime/runtime");

完全无需手动管理！

实战建议：企业级项目的最佳实践

在一个典型的 React + Webpack 项目中，我推荐以下配置组合：

1. 统一使用.browserslistrc

创建.browserslistrc文件，统一多工具共享目标环境：

> 0.5% last 2 versions Firefox ESR not dead ie >= 11

然后在babel.config.json中直接引用：

{ "presets": [ [ "@babel/preset-env", { "useBuiltIns": "usage", "corejs": { "version": 3 } } ], "@babel/preset-react" ] }

不需要再写targets，preset-env会自动读取 browserslist 配置。

2. 入口文件不再需要全局 polyfill

以前我们习惯在index.js写：

import '@babel/polyfill'; // ❌ 已废弃

现在完全不需要！因为useBuiltIns: "usage"已经帮你精准注入所需内容。

⚠️ 注意：@babel/polyfill在 Babel 7.4 后已被弃用，请改用core-js+regenerator-runtime。

3. Webpack 层也要配合

确保optimization.splitChunks和runtimeChunk合理配置，避免 polyfill 被重复打包：

// webpack.config.js module.exports = { optimization: { splitChunks: { chunks: 'all', cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: 'vendors', priority: 10 } } }, runtimeChunk: 'single' // 抽离运行时代码 } };

这样可以防止多个 entry 共享的 helper 函数（如_asyncToGenerator）被重复打包。

常见坑点与避坑指南

✅ 特别提醒：不要轻易开启loose模式或禁用useBuiltIns来“提速”，这可能导致语义偏差或兼容性回退。

写在最后：转译不是妥协，而是自由

有人觉得用 Babel 是一种“倒退”，仿佛在向旧时代低头。但我想说，真正的工程自由，不是只为自己写代码，而是在满足业务需求的前提下，依然能使用最先进的语言特性。

正确的 Babel 配置，不是负担，而是杠杆。它让我们既能写出简洁优雅的async/await和按需加载的import()，又能平稳运行在千差万别的终端设备上。

当你下次看到“regeneratorRuntime is not defined”时，不要再慌张地到处贴补丁。静下心来检查你的preset-env配置，确认useBuiltIns是否启用，.browserslistrc是否准确。

一旦掌握这套机制，你会发现：所谓兼容性难题，不过是几个配置项的距离。

如果你正在搭建新项目，或者想重构老项目的构建流程，不妨从这一套配置开始。它已经在多个大型后台系统、H5 活动页和跨端组件库中经过验证，稳定可靠。

欢迎在评论区分享你的 Babel 配置经验，我们一起打造更高效的前端工程体系。