CRA中JavaScript ??运算符polyfill为何用void 0而非undefined

核心逻辑出发点 #

JS语法的历史设计缺陷，决定了直接写foo !== undefined的可靠性远低于foo !== void 0。
你之前验证的void 0 === undefined在现代标准环境下确实成立，但转译输出的代码需要适配尽可能老旧、甚至存在异常篡改行为的JS运行环境，不能依赖环境本身对undefined变量的保护。
undefined 从JS诞生之初就不是语言保留关键字，它只是全局作用域下的一个预定义普通变量。在ES5之前的所有非严格运行环境中，这个变量完全可以被任意修改、覆盖。
举个实际会引发逻辑错误的代码示例：

// 以下代码在老版本浏览器、非严格模式下可正常运行，不会抛出报错
function getFallbackValue(foo) {
  // 在函数作用域内重新定义名为undefined的局部变量
  var undefined = '自定义的字符串值';
  // 此时判断逻辑完全失效——哪怕foo是真正的原始undefined，也会和局部被篡改的undefined变量做比较
  return foo !== undefined ? foo : 'default value';
}

getFallbackValue(undefined) // 实际返回字符串 "undefined"，而非预期的 "default value"

为什么void 0是稳妥的替代方案 #

void 是JS的保留关键字，它的固定语义是：对后面的操作数完成求值后，永远返回语言层面定义的、未被任何代码篡改的原始undefined值。这个写法具备两个核心优势：

• 不存在被作用域变量覆盖篡改的可能，因为关键字是语言层面固定的，不能被用户代码重定义
• 代码长度极短，比起写一长串获取真实undefined的兼容判断，直接输出void 0能减少打包后的代码体积

对应你看到的CRA编译产物说明 #

虽然从ES5开始，全局作用域下的undefined被设为了不可写、不可配置的属性，现代环境下篡改全局undefined的实际影响已经非常小，但Babel（create-react-app底层使用的JS转译工具）从兼容性优先的角度出发，依然会默认把所有涉及undefined判断的场景，替换为void 0的写法。
你观察到的空值合并运算符转译逻辑foo !== null && foo !== void 0 ? foo : 'default value'，就是这个通用转译策略的具体体现：它完整还原了??运算符“左侧值不为null、也不为undefined时返回左侧，否则返回右侧”的核心语义，同时保证了逻辑在任何JS运行环境下都不会因变量篡改出现偏差。

内容的提问来源于stack exchange，提问作者Robo Robok