Babel与Polyfill
约 588 字大约 2 分钟
2026-02-11
很多项目“看起来配了 Babel”却依然在旧浏览器报错，根本原因通常是：把语法降级和 API 补齐混为一谈。
这个章节的目标是把三件事讲清楚：
- Babel 负责什么。
- Polyfill 负责什么。
- Browserslist 如何成为全项目的兼容基线。
Babel 与 Polyfill 的边界
先看结论：
- Babel：把“写法”变成旧环境能识别的写法。
- Polyfill：给旧环境补上缺失的“运行时能力”。
例如：
- 箭头函数 -> 普通函数：Babel 可处理。
Promise、Array.prototype.includes：需要 Polyfill。
重要
语法转换不等于 API 实现，两个都要配才叫“完整兼容方案”。
基础安装
pnpm add -D babel-loader @babel/core @babel/preset-env
pnpm add core-js regenerator-runtimeBabel 配置为什么这样写
你会看到 corejs 和 useBuiltIns，它们正是“按需注入 Polyfill”的核心。
// babel.config.cjs
module.exports = {
presets: [
[
'@babel/preset-env',
{
// 与安装的 core-js 主版本保持一致
corejs: 3,
// usage: 根据源码使用到的 API 自动注入 polyfill
useBuiltIns: 'usage',
},
],
],
};然后让 Webpack 在 JS 文件上使用 Babel：
// webpack.config.cjs（节选）
module.exports = {
module: {
rules: [
{
test: /\.m?js$/,
exclude: /node_modules/,
use: 'babel-loader',
},
],
},
};Browserslist：兼容目标统一入口
很多工具都会读取 Browserslist（Babel、Autoprefixer 等），所以它应该成为团队统一标准。
# .browserslistrc
> 1%
last 2 versions
not dead如果你在 Babel 里又单独写 targets，会覆盖 Browserslist。除非有明确原因，否则不建议这样做。
useBuiltIns 怎么选
| 取值 | 行为 | 适用场景 |
|---|---|---|
false | 不自动注入 Polyfill | 已有外部 Polyfill 方案 |
usage | 按使用自动注入 | 大多数业务项目首选 |
entry | 入口全量注入 | 对第三方未转译依赖兼容性要求极高 |
useBuiltIns 选型
使用注意事项
建议
corejs版本与依赖版本保持一致。- 优先
usage，减少不必要 Polyfill。 - 兼容策略统一收口到 Browserslist。
常见错误
- 包名写错：
@babel/@preset-env（错误）应为@babel/preset-env。 - 忘记安装
core-js，导致运行时仍缺 API。 - 盲目转译
node_modules，显著拖慢构建。
最佳实践
- 把“兼容目标”当作团队公共契约，而不是个人本地偏好。
- 定期复盘浏览器支持范围，及时下调历史包袱。
- 为关键页面建立低版本浏览器回归用例。