core-js 与 core-js-pure 的区别：怎么选择以避免全局污染

前端工程化 · Polyfill 指南

在现代前端工程中，core-js 负责为目标运行环境注入最新的 ECMAScript 特性实现，是 Babel、SWC 等转译工具的底层基石；而 core-js-pure 是 core-js 官方维护的“无污染版本”，两者最大的差别在于是否对 JavaScript 运行时的全局对象及原生原型链进行改写。如果你正在构建独立的业务应用，使用 core-js 可以享受到完全符合规范的原生语法与最小的代码包装开销；但如果你正在编写并发布一个开源库、NPM 组件、通用 SDK 或微前端子应用，直接使用 core-js 会在宿主环境造成不可逆的全局污染，此时 core-js-pure 是唯一安全的标准解决方案。

一、底层机制差异：原型链补丁 vs 局部命名空间

理解两者区别的前提，是看清 Polyfill 在浏览器运行时中究竟做了什么。当我们需要在不支持 Array.prototype.includes 或 Promise 的旧环境中使用这些特性时，有两种完全不同的兼容思路：

• core-js 的做法（全局侵入）：直接检测 window.Promise 或 Array.prototype.includes 是否存在。如果不存在或实现不符合现代规范，就直接修改 window 对象或向 Array.prototype 挂载自己的函数。这意味着脚本一旦执行，全局环境就永远被改写了。
• core-js-pure 的做法（沙箱隔离）：完全不碰 window，也不动任何原型链。它把每个 ES 特性封装成独立的纯函数或构造函数导出。例如导出一个独立的 Promise 类，或者导出一个接收数组并执行判定的 includes(arr, item) 工具函数。代码中用到的地方由编译器重写为局部变量导入，与外部宿主环境实现物理隔离。

如上图所示，当你在项目中执行 import "core-js/stable" 时，所有的修改都会作用在宿主进程的根作用域上；而 core-js-pure 则是通过模块导入的方式将功能引入私有命名空间，外部宿主看不到任何变化。

二、为什么全局污染对第三方库是致命的？

许多开发者在开发业务系统时习惯了使用 core-js，但在将公共工具或组件打包发布给外部使用时，如果不慎将全局 core-js 混入产物，往往会引发难以排查的线上事故：

1. Polyfill 版本踩踏与冲突：宿主项目可能使用的是 core-js@3.30，而你的 SDK 打包了 core-js@3.15。当两者同时向 Promise.prototype.finally 写入补丁时，后加载的代码会覆盖先加载的代码，造成规范实现不一致或隐藏 Bug。
2. 破坏第三方特意定制的 Mock 或猴子补丁：某些应用或测试框架为了监控、埋点或安全防护，特意劫持了 fetch 或 Promise。第三方库一旦强行覆盖全局对象，就会导致宿主的监控或代理逻辑彻底失效。
3. 微前端与多子应用环境的全局交叉干扰：在 qiankun、single-spa 等微前端架构中，若子应用未开启完全严格的沙箱，一个子应用引入全局 core-js 修改了 Array.prototype，会直接泄露到基座应用和其他子应用中，打破各子系统之间的隔离边界。

三、选型决策路径：怎么选择适合你的方案？

选择哪一个方案并不是看哪个“更高级”，而是取决于当前代码的宿主所有权与分发形态。我们可以通过清晰的决策树来快速锁定方案：

1. 场景 A：开发业务应用（Web 单页应用 / 管理后台 / 独立站点）

选型结论：选择 core-js

原因：作为业务系统的开发者，你对当前的浏览器运行环境拥有完全的控制权。使用 core-js 配合 @babel/preset-env 的 useBuiltIns: 'usage'，编译器可以根据你的 .browserslistrc 目标浏览器清单，精准按需向全局注入缺失补丁。这样做不仅代码更加直观，避免了对每个实例方法做额外的包装函数调用，而且打包产物体积通常最为紧凑。

2. 场景 B：开发通用类库、组件库、SDK 或插件

选型结论：选择 core-js-pure

原因：你的代码将被打包后安装在未知版本的宿主项目中。使用 core-js-pure 配合 @babel/plugin-transform-runtime，可以确保你的库即使在极老的浏览器（如 IE 11）下运行 ES6+ 语法，也不会触碰宿主的一丝一毫，给使用者提供极致的稳定性和专业度。

四、实操指南：在工程中配置 core-js-pure

开发者通常不需要手动编写形如 import _Promise from 'core-js-pure/actual/promise' 的冗长代码。在现代工程流水线中，这一转换由 Babel 插件自动完成。以下是标准的三步配置流程：

第一步：安装依赖

注意明确区分开发依赖（编译期插件）与生产依赖（运行时代码）：

# 1. 编译期插件（仅构建时需要，存入 devDependencies）
npm install --save-dev @babel/plugin-transform-runtime @babel/preset-env

# 2. 运行时内嵌垫片（宿主运行时需要，存入 dependencies）
# @babel/runtime-corejs3 内部直接依赖并封装了 core-js-pure
npm install --save @babel/runtime-corejs3

第二步：编写 Babel 配置文件

在项目根目录创建或修改 babel.config.json（或 .babelrc）：

{
  "presets": [
    [
      "@babel/preset-env",
      {
        // 注意：开发公共库时，务必将 useBuiltIns 设为 false 或不配置
        // 防止 preset-env 再次引入全局 core-js 导致污染
        "useBuiltIns": false
      }
    ]
  ],
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        // 指定 corejs 版本为 3，插件将自动引入 @babel/runtime-corejs3 (基于 core-js-pure)
        "corejs": { "version": 3, "proposals": true },
        "helpers": true,
        "regenerator": true
      }
    ]
  ]
}

第三步：验证构建产物代码

假设你的源码中写下了常见的 ES6+ 代码：

// 源码 src/index.js
export function fetchData() {
  return new Promise((resolve) => {
    const list = [1, 2, 3];
    const found = list.includes(2);
    resolve(found);
  });
}

经过 Babel 编译输出后，观察打包出的代码：

// 编译产物 dist/index.js（示例截取）
import _Promise from "@babel/runtime-corejs3/core-js-pure/actual/promise";
import _includesInstanceProperty from "@babel/runtime-corejs3/core-js-pure/actual/instance/includes";

export function fetchData() {
  return new _Promise(function(resolve) {
    var list = [1, 2, 3];
    var found = _includesInstanceProperty(list).call(list, 2);
    resolve(found);
  });
}

可以看到，代码中的 Promise 被自动映射为局部导入的 _Promise，而数组实例方法 list.includes(...) 被自动转换为了纯函数 _includesInstanceProperty。全局的 window.Promise 和 Array.prototype 从始至终没有发生任何改动。

五、实例方法 Polyfill 的特殊考量

静态方法（如 Promise.resolve()、Object.assign()）由于有明确的对象名，Babel 重写起来非常简单。但对于实例方法（如 [].includes()、''.padStart()），JavaScript 作为动态类型语言，Babel 在静态编译时往往无法准确推断某个变量到底是数组还是自定义对象。

为了做到在不修改 Array.prototype 的前提下让实例方法正常工作，@babel/plugin-transform-runtime 在配合 core-js-pure（即 corejs: 3）时，会将所有形如 obj.includes(...) 的调用都重写为辅助包装函数。这也带来了一定的权衡：

• 运行开销微量增加：原本直接调用原生方法，现在需要经过一层包装判断（先检测该对象原生是否支持，不支持再调用 pure 垫片）。
• 代码体积相对增大：由于需要引入对实例方法的包装逻辑，生成的模块导入语句会比直接挂载原型的 core-js 多出一些辅助代码。

这就是为什么在完全由自己把控环境的业务单页应用中，依然建议采用 core-js + preset-env：在拥有环境掌控权时，不必为追求无污染而承担额外的包装体积与运行间接开销。

六、全景对比与总结

为了帮助你在技术评审与日常开发中迅速决策，我们将 core-js 与 core-js-pure 的核心差异归纳为以下全景对比矩阵：

回顾两者定位，核心原则非常简单明确：“业务应用放心用 core-js，类库 SDK 严禁污染必须用 core-js-pure”。掌握这两者的差异与 Babel 的工程化配合方式，不仅能避免在开源协作中出现尴尬的全局污染 Bug，更能帮助你在面对复杂的跨端、微前端及基础架构场景时，做出最为严谨可靠的技术选择。