Modern JavaScript Tutorial：用 Polyfill 与 Transpiler 让现代代码兼容旧引擎
Modern JavaScript Tutorial：用 Polyfill 与 Transpiler 让现代代码兼容旧引擎
本篇指南以 Modern JavaScript Tutorial 的 Polyfills and transpilers 章节为核心，系统讲解"语言标准演进快、引擎实现滞后"的兼容性难题，以及社区的两大解决方案：Transpiler（转译器）与 Polyfill（垫片）。读完你将理解两者各自的适用场景、工作原理与典型实现模式，并能在 Babel、webpack 等构建体系中正确落地，让现代语法与新版内置函数安全运行在老旧浏览器上。
背景：语言在演进，引擎却各怀心事
JavaScript 是一门仍在持续演进的编程语言。新的语言提案（proposal）会定期出现，经过 TC39 委员会的分析与评审，若被认为有价值，就会被纳入规范（ECMA-262）的待办清单，进而一步步推进为正式标准。
然而，各大 JavaScript 引擎（V8、SpiderMonkey、JavaScriptCore 等）背后的团队对"先实现什么"有各自的取舍。他们可能优先实现仍在草案阶段的提案，而推迟规范中已经定稿、但"不那么有趣"或"实现难度更高"的特性。因此，一个非常常见的现实是：引擎只实现了标准的一部分，不同浏览器对同一特性的支持程度参差不齐。
如果你想了解各语言特性当前的支持状态，业界有两个常被引用的参考页面：
- compat-table（ECMAScript 兼容性对照表）：覆盖纯 JavaScript 语法与内置对象特性；
- caniuse：覆盖浏览器相关的 Web API 与功能。
小提示：Google Chrome 通常对语言新特性的跟进最快。如果本教程中的某个演示在你当前浏览器中运行失败，可以优先尝试用 Chrome 打开——不过绝大多数教程演示在任何现代浏览器中都能正常工作。
作为开发者，我们当然希望尽量使用最新、最好用的语言特性——"好东西越多越好"。但问题随之而来：如何让现代代码跑在那些还不认识这些新特性的旧引擎上？ 答案就是本章的两个主角：Transpilers 与 Polyfills。
两大工具的分工：语法交给 Transpiler，函数交给 Polyfill
先给结论，便于后面展开：
| 兼容目标 | 工具 | 本质 |
|---|---|---|
新语法、新操作符（如 ??、箭头函数、class） |
Transpiler（转译器） | 把现代源码改写为等价的老语法源码 |
新内置函数/对象（如 Math.trunc、Promise） |
Polyfill（垫片） | 在运行时"补上"缺失的函数实现 |
Transpilers：把现代语法翻译成旧引擎听得懂的话
Transpiler（转译器） 是一种特殊的软件：它把源代码翻译成另一份源代码。它能解析（parse，"读懂"）现代代码，然后用更旧的语法结构重写它，使改写后的代码也能在过时的引擎中运行。
一个最典型的例子来自本仓库的 Nullish coalescing operator '??' 章节：2020 年之前，JavaScript 并没有空值合并操作符 ??。如果访问者使用过时的浏览器，它可能无法理解下面这行代码：
height = height ?? 100;
转译器会分析这段代码，把 height ?? 100 改写成等价的旧语法形式：
// 转译前
height = height ?? 100;
// 转译后
height = (height !== undefined && height !== null) ? height : 100;
改写后的代码，旧的 JavaScript 引擎就能正常识别了。
为什么可以这样改写？因为 ?? 的语义本身就不复杂。在 ?? 运算符章节 中可以看到，result = a ?? b 的完整等价形式正是：
result = (a !== null && a !== undefined) ? a : b;
也就是说，?? 返回第一个"既不是 null 也不是 undefined"的参数，否则返回第二个参数。转译器所做的，正是把这种语法糖还原成底层等价代码。注意这与 ||（返回第一个真值）有本质区别：height = 0 时，height || 100 得到 100，而 height ?? 100 得到 0——因为 0 是 falsy 但并非 null/undefined，这正是 ?? 更精确控制默认值的价值所在。
转译器的典型工作流程是：开发者在自己的电脑上运行转译器，生成转译后的代码，再把产物部署到服务器上——转译发生在构建阶段，而不是浏览器运行时。
说到名字，Babel 是目前最著名的转译器之一。而现代项目构建系统，如 webpack，则提供了一种机制：在每次代码变更时自动运行转译器，从而非常轻松地把转译集成到日常开发流程中。
Polyfills：给缺失的内置函数"填坑"
新的语言特性不仅包含语法结构和操作符，也可能包含内置函数。例如 Math.trunc(n) 会"截掉"一个数字的小数部分：Math.trunc(1.23) 返回 1。但在某些（非常老旧的）JavaScript 引擎中根本没有 Math.trunc，这样的代码就会直接报错。
这里的关键区别在于：我们面对的是新函数，而不是语法变化，因此无需转译任何东西——只需要声明那个缺失的函数即可。这种"更新/补充新函数"的脚本就被称为 Polyfill：它"填补"了引擎的能力缺口，补上缺失的实现。
手写一个 Math.trunc polyfill
针对上面这个例子，Math.trunc 的 polyfill 就是一个实现它的脚本，典型写法如下：
if (!Math.trunc) { // 如果不存在该函数
// 实现它
Math.trunc = function(number) {
// Math.ceil 和 Math.floor 即使在古老的 JavaScript 引擎中也存在
// （它们将在教程后续章节中讲解）
return number < 0 ? Math.ceil(number) : Math.floor(number);
};
}
这段代码的精妙之处在于：它只依赖 Math.ceil 与 Math.floor 这两个"古老引擎也早就支持"的函数来合成 Math.trunc 的行为。
在 数字类型章节 的取整小节中，本仓库给出了四种取整函数的完整对照表，正好可以印证 polyfill 的写法与语义：
Math.floor |
Math.ceil |
Math.round |
Math.trunc |
|
|---|---|---|---|---|
3.1 |
3 |
4 |
3 |
3 |
3.5 |
3 |
4 |
4 |
3 |
3.6 |
3 |
4 |
4 |
3 |
-1.1 |
-2 |
-1 |
-1 |
-1 |
-1.5 |
-2 |
-1 |
-1 |
-1 |
-1.6 |
-2 |
-1 |
-2 |
-1 |
可以看到：Math.floor 向下取整、Math.ceil 向上取整、Math.round 就近取整（3.5 向上、-3.5 也是向上），而 Math.trunc 直接丢弃小数部分不做任何舍入。该章节还特别注明 Math.trunc 不被 Internet Explorer 支持——这正是需要 polyfill 的典型场景。
由此也理解了 polyfill 实现中的分支逻辑：对负数（如 -1.1，trunc 结果应为 -1）用 Math.ceil（-1.1 → -1），对非负数（如 3.1，trunc 结果应为 3）用 Math.floor（3.1 → 3），两者组合恰好还原了"直接截断小数部分"的语义。
为什么可以这样"补"？
JavaScript 是一门高度动态的语言：脚本可以添加或修改任何函数，即使是内置函数也不例外。Polyfill 正是利用了这一特性——通过给全局对象补充方法，让缺失的内置函数在运行时"原地复活"。关于脚本如何访问和扩展全局内置对象，可参考本仓库的 Global object 章节（该章节同样出现了 polyfill 一词，用于说明给全局对象补充内置方法这一常见做法）。
另外值得留意的是动态修改内置对象这一操作的边界：在现代工程实践中，通常建议把 polyfill 放在脚本最前面、或在模块化代码中通过按需引入来加载；同时，由于模块（module）与 class 会自动启用严格模式（见 The modern mode, "use strict" 与 Modules, introduction），在严格模式下修改/新增全局内置对象时需遵循相应的规范与约定，避免与未来引擎原生实现产生冲突。
专业的 polyfill 库：core-js
手写 polyfill 适合理解原理，生产环境则更推荐成熟的社区方案。一个广受关注的 polyfill 库是 core-js：它支持的特性非常多，并且允许只引入你需要的那些特性，避免整包引入带来的体积浪费。
决策指南：什么时候用哪个？
综合本章内容，可以给出一个清晰的选择框架：
- 使用了现代语法或操作符（如
??、可选链?.、箭头函数、class）→ 使用 transpiler（如 Babel）； - 使用了可能缺失的内置函数（如
Math.trunc、Array.prototype.includes）→ 使用 polyfill（如 core-js，或手写if (!Math.trunc) {...}模式）； - 两者皆有（例如依赖
Promise这类新对象，同时又使用async/await语法）→ 转译器与 polyfill 配合使用：语法层交给 Babel，能力层交给 polyfill。
这套组合拳的最终效果是：你可以放心地学习和使用最新、甚至"前沿"的语言特性，不必因为引擎支持滞后而束手束脚——只要记得在构建阶段用转译器处理语法，在运行时用 polyfill 补齐函数即可。
集成到构建流程：webpack + babel-loader
原文档给出的落地建议是：等你熟悉 JavaScript 之后，可以基于 webpack 搭建一套代码构建系统，并配合 babel-loader 插件使用。其典型工作方式为：
- 源码中使用现代语法与新函数；
- webpack 监听代码变更，自动调用 babel-loader 完成转译（语法层面降级）；
- polyfill 以依赖或入口脚本形式随打包产物引入（能力层面补全）；
- 最终将构建产物部署到服务器，旧引擎也能运行。
借助这种"构建时自动转译 + 运行时垫片补全"的流水线，兼容性处理对日常开发几乎透明，开发者可以把精力集中在语言本身。
总结
本章的核心结论非常明确，值得反复体会：
- JavaScript 语言持续演进，但引擎对标准的实现总是参差不齐——这是兼容性问题的根源；
- Transpiler（转译器） 负责把现代语法/操作符改写为等价的旧语法（典型案例：
height ?? 100→(height !== undefined && height !== null) ? height : 100），代表工具是 Babel，可无缝集成于 webpack 等构建系统； - Polyfill（垫片） 负责在运行时补充缺失的内置函数（典型案例：
if (!Math.trunc) { Math.trunc = ... }），JavaScript 的高度动态性保证了这种"补丁"的可行性，代表库是 core-js； - 实践建议：大胆学习、使用最新语言特性，同时用转译器处理语法、用 polyfill 补齐函数，二者共同保证代码在旧环境中正常工作。
想进一步查阅支持状态，可参考 compat-table（纯 JavaScript 特性）与 caniuse（浏览器相关函数/API）。若本教程中的演示代码在你的浏览器中运行失败，优先试试 Chrome——它通常对语言新特性的支持最为超前。