core-js 是什么：JavaScript ES6+ Polyfill 的作用与原理

core-js 是目前 JavaScript 生态中被最广泛采用的标准库 Polyfill（垫片）核心。它的核心使命是为不支持现代 ECMAScript 规范的旧版运行环境（包括老旧浏览器与陈旧的 Node.js 版本），完整补充缺失的内置对象、静态工具方法以及实例原型方法。无论是使用现代前端框架编写应用，还是通过 Babel 进行代码转译，绝大部分新特性在低版本引擎上的平稳运行都由 core-js 在幕后提供支撑。

一、为什么需要 Polyfill：语法转译与 API 缺失的本质区别

初学者在接触 Babel 等构建工具时，容易产生一种误解：只要在工程中配置了 Babel，代码就能在任何老旧浏览器中运行。然而，JavaScript 规范的演进分为两个维度：新语言语法与新标准 API。

• 语言语法层面：如箭头函数 () => {}、变量解构赋值 const { id } = item、类语法 class Person {}。这类语法属于解析阶段的文法结构，旧引擎在遇到它们时会在词法分析阶段直接抛出 SyntaxError: Unexpected token。Babel 这类编译器通过 AST（抽象语法树）转换，能够将其机械式地改写为 ES5 的传统 function 和普通对象赋值。
• 标准 API 层面：如异步流程控制对象 Promise、基础类型 Symbol、字典结构 Map / Set，以及实例原型方法 Array.prototype.includes、String.prototype.padStart 和静态方法 Object.assign。这些属于运行时的全局属性与对象方法。语法编译器无法通过简单的字面替换让旧环境凭空拥有它们；如果在旧引擎中直接调用，会触发 ReferenceError: Promise is not defined 或 TypeError: arr.includes is not a function。

Polyfill（垫片）的定义便由此而来：它是一段在运行时先于业务逻辑执行的脚本，专门用于“填平”旧环境宿主与现代 ECMAScript 规范之间的功能沟壑。而 core-js 正是现代前端工程中最为核心的模块化 Polyfill 实施库。

二、core-js 的内部架构与模块化分层

core-js 之所以能成为行业事实标准，关键在于其精细的模块化架构设计。它不是一段笨重且不可分割的单一脚本，而是由数百个细分特性模块构成的功能网络。

从架构自顶向下观察，core-js 包含三大入口与两层核心支撑：

1. 标准全局包（core-js）：直接扩展当前环境的全局对象（如 window、globalThis）以及原生构造函数的 prototype。开发者在代码中可以直接书写规范标准的语法，体验如同在原生支持的高版本环境中编程。
2. 纯净沙箱包（core-js-pure）：不修饰任何全局对象和原型链，将所有 Polyfill 方法导出为独立的工具函数。例如通过返回包装对象模拟 Map 或 Promise，专供公共库与微前端子模块使用，避免污染主宿主环境。
3. 特性兼容性元数据（core-js-compat）：维护了一份庞大且精确的映射矩阵，记录每个 ECMAScript 特性在各个浏览器具体版本中的支持情况，是 Babel @babel/preset-env 实行按需加载的底层依据。
4. 规范实现层（es.*、web.*、proposals.*）：涵盖从正式发布的 ECMAScript 标准，到 DOM 集合迭代器（如 NodeList.prototype[Symbol.iterator]），再到处于 TC39 讨论阶段的提案。
5. 内部底层操作引擎（core-js/internals）：封装了符合 ECMAScript 规范的一系列抽象操作，如类型安全转换、符号检测、内部原型保护机制等，确保垫片本身的执行性能与安全性。

三、core-js 的底层实现原理

编写一个合格的 Polyfill 远不仅是在 Array.prototype 上挂载一个函数那么简单。core-js 在底层遵循极严谨的规范与边界保护策略：

1. 特性检测优先（Feature Detection）

core-js 不会盲目覆盖宿主原本已有的方法。在加载每个模块时，它首先执行特性检测（Feature Detection）。只有当当前宿主完全缺少该 API，或者宿主原生实现存在已知缺陷（Buggy Implementation，例如早期部分浏览器中 Array.prototype.slice 对非标准对象处理不符合规范）时，才会激活替补实现。

2. 属性描述符与不可枚举保护

在 ECMAScript 规范中，原型上的原生方法默认是不可枚举的（enumerable: false）。若通过普通的 Array.prototype.includes = function() {} 赋值，会导致开发者使用 for...in 循环遍历数组时，遍历出垫片方法名称，破坏既有业务逻辑。

core-js 在内部统一通过 Object.defineProperty 进行挂载，严格限制描述符：

// core-js 内部挂载方法的原理抽象示意
var defineBuiltIn = function (target, key, value) {
  Object.defineProperty(target, key, {
    value: value,
    writable: true,
    configurable: true,
    enumerable: false // 关键：禁止被 for...in 循环枚举
  });
};

3. 严谨对齐规范抽象操作与边界情况

例如在实现 Array.prototype.includes 时，不仅要处理常规值，还必须严密遵守规范对 NaN 的比较规则（原生 indexOf 无法识别 NaN，但 includes 规定 [NaN].includes(NaN) === true），并对 to-length、to-integer-or-infinity 以及负索引偏移计算进行完全拟合。

四、工程化集成：Babel 与 core-js 的协同流水线

在现代构建流程（如 Webpack、Vite、Rollup）中，开发者极少手动按文件逐个 import "core-js/modules/es.promise"。我们通常借助 Babel 的预设 @babel/preset-env 配合 core-js 实现智能化编译。

在 babel.config.json 中，最为核心的配置是 useBuiltIns 选项：

// babel.config.json 生产推荐配置
{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "browsers": ["> 0.5%", "last 2 versions", "not dead", "iOS >= 12"]
        },
        "useBuiltIns": "usage", // 核心策略：按代码实际用量自动引入
        "corejs": {
          "version": 3,
          "proposals": false
        }
      }
    ]
  ]
}

useBuiltIns 参数的三种选项效果存在明确差异：

• false（默认值）：Babel 不处理任何 Polyfill。开发者若要在旧环境运行，必须自行在入口引入完整的垫片库，打包体积往往最大。
• "entry"：开发者在工程主入口手动写入 import "core-js";。Babel 会根据 targets 声明的目标浏览器列表，将这行全量引入拆解并替换为目标环境所必需的数十个具体子模块。
• "usage"（推荐模式）：Babel 结合 AST 遍历，扫描每个源码文件中实际调用的 API。如果文件中使用了 Promise，且目标浏览器中缺少 Promise，Babel 才会静默在该文件头部插入 import "core-js/modules/es.promise";。真正实现“用多少补多少”。

五、模式对比：全局注入 vs 纯净沙箱（core-js-pure）

在前端架构设计中，宿主所有权的不同决定了使用 Polyfill 的策略截然不同。

六、生产实践关键避坑清单

在实际项目落地中，针对 core-js 的配置有几个高频踩坑点需要重点防范：

1. 避免在业务入口全量引入：切勿既配置了 useBuiltIns: "usage"，又在主入口写下 import "core-js"。这会导致垫片代码被重复打包，使最终 JavaScript 产物体积徒增数百 KB。
2. 严格锁定主版本号：core-js 经历过 v2 到 v3 的重大架构重组。在安装依赖时若使用了 npm install core-js@3，Babel 配置中必须明确显式指定 "corejs": 3。若遗漏指定，Babel 默认可能会按照 v2 格式生成模块路径，导致打包阶段抛出 Module not found 错误。
3. 第三方依赖中的 API 穿透：大多数脚手架在配置 babel-loader 时会排除 node_modules（exclude: /node_modules/）。如果项目中引入的某个未充分编译的 NPM 依赖使用了 Promise.finally 或 flat，而该依赖未自带垫片，且 Babel 因排除了该目录未能检测到对应调用，页面在低版本浏览器中就会发生运行时崩溃。遇到该情况时，应将该依赖包名加入构建转译的白名单中。