为什么JS开发中推荐用void 0代替undefined？

作者：木棉

时间：2026-10-30

深入解析在JavaScript开发中推荐使用void 0代替undefined的核心原因，包括变量作用域遮蔽隐患、代码体积压缩收益以及现代开发环境下的最佳实践。

文章目录

在 JavaScript 源码库（如 Underscore、Lodash）及 Webpack、Terser 等现代构建压缩工具中，我们经常能看到使用 void 0 代替 undefined 的写法。其核心原因只有两个：一是规避作用域中 undefined 变量被局部重写或意外遮蔽所带来的取值风险；二是在源码打包压缩时直接节省字节开销（void 0 占 6 字符，而 undefined 占 9 字符）。

许多初入 JavaScript 的开发者往往下意识认为 undefined 是一个像 null、true、false 一样的不可变保留关键字。然而在语言底层规范中，它的待遇完全不同。本文将从语言机制、作用域链行为、一元操作符原理以及构建工具优化四个维度，逐层拆解为什么 void 0 是获取纯正未定义值的工业标准方案。

图1：void 0 与 undefined 的语言机制与安全性差异概览

一、undefined 为什么不是绝对安全的？

在 JavaScript 的关键字列表（如 null、function、var、return 等）中，并没有 undefined 的身影。在早期的 ECMAScript 规范中，undefined 只是挂载在全局对象（window 或全局上下文）上的一个普通属性。

这带来了两个历史与设计上的遗留现象：

1. 全局修改历史（ES3 时代）

在 ECMAScript 3 标准中，全局的 undefined 甚至是可写的。这意味着任何第三方脚本只需要执行一句 window.undefined = "compromised";，整个运行环境中所有基于 if (val === undefined) 的条件判断将全线崩溃。虽然在 ECMAScript 5 规范确立后，全局的 undefined 被设定了 writable: false 和 configurable: false 属性描述符，现代浏览器下全局 undefined 已经不能直接赋值改写，但这只解决了全局作用域的问题。

2. 局部作用域遮蔽（Variable Shadowing）

由于 undefined 依旧不是保留关键字，开发者在任何局部作用域（函数内或代码块内）依然可以合法地将其声明为局部变量或函数形参。一旦局部变量命名为 undefined，当前作用域链查找就会发生“遮蔽现象”。

// 局部作用域遮蔽示例
function checkStatus(val) {
  // 声明了一个名为 undefined 的局部变量
  var undefined = "not-empty";

  console.log(val === undefined); 
}

checkStatus(); // 输出：false！原本无传参的 val 无法匹配 undefined

不仅如此，在较早版本或无严格模式下，如果函数形参中包含了 undefined，外部调用传入参数时同样会改变函数内部 undefined 的值：

function evaluateParam(data, undefined) {
  // 若调用方传入 evaluateParam("test", "hacked")
  // 此时函数内的 undefined 变量值就变成了 "hacked"
  return data === undefined;
}

图2：作用域链查找对比——标识符查询 vs 原生一元操作符求值

二、void 运算符的本质与推导机制

为了获得绝对安全且不可被任何宿主代码改写的 undefined，JavaScript 设计了一元操作符 void。

根据 ECMAScript 官方规范对 void 运算符的求值算法定义：

求值其后所带的表达式（Evaluate the expression）。
调用 GetValue(result) 解析其操作数。
无条件返回语言底层的原始值 undefined。

也就是说，无论 void 后面跟的是什么表达式，它的最终返回值永远是纯正的 undefined。

void 0;          // 返回 undefined
void 1;          // 返回 undefined
void "hello";    // 返回 undefined
void (1 + 2);    // 返回 undefined
void (Math.random()); // 计算了 random()，丢弃结果并返回 undefined

那为什么大家约定俗成写 void 0，而不是 void 1 或 void null 呢？

因为数字 0 是合法表达式中最短、求值开销最小、视觉认知最直观的字面量。写成 void 0 既没有额外的运算开销，又将整个语句缩短到了极限的 6 个字符。

图3：void 0 执行步骤推导与规范围绕逻辑

三、打包工具与代码体积压缩收益

除了防御变量遮蔽外，void 0 的流行还有极为现实的工程原因：代码压缩（Minification）。

对比两者的字符长度：

undefined：一共占用 9 个字符（9 字节）。
void 0：一共占用 6 个字符（6 字节）。

每一次替换直接节省 3 个字符（降幅达 33.3%）。在大型单页应用（SPA）或组件库中，由于判断默认传参、初始化变量、空值检测等高频逻辑，undefined 的引用次数往往达到成百上千次。

压缩工具的自动化转换：在当今的工业化前端构建中，无论是 Webpack、Vite、Rollup 还是底层工具 Terser、esbuild、UglifyJS，都在生产压缩配置中默认开启了此项优化。开发阶段你写的是 undefined，打包产物中会被编译器自动转化为 void 0。

图4：构建打包时压缩器自动将 undefined 转换为 void 0 的流程

四、日常开发与工程实践建议

既然 void 0 既安全又省体积，那么在当今的日常业务开发中，我们是否需要强行在每一行代码里把 undefined 全部手写成 void 0？

答案是：需要根据具体的开发场景进行权衡，不需要一刀切。

开发场景	推荐写法	决策原因
业务应用（TypeScript / Vue / React）	`val === undefined` 或使用可选链 `?.`、空值合并 `??`	1. 现代工程普遍开启严格模式（Strict Mode）与 ESLint，变量遮蔽会被静态检测直接拦截。 2. 提升代码的可读性与团队协作维护效率。 3. 生产打包工具（esbuild/Terser）会自动执行字符优化，无需人工手动转换。
底层开源类库（SDK / 框架内核）	`void 0`	1. 作为底层库无法预知被引用的宿主执行环境是否可靠、是否含有非严格模式脚本。 2. 追求极限防御与对古老运行时的向下兼容性。
HTML 行内链接占位	`javascript:void(0)`	当需要在 `<a href="...">` 中阻止页面向上跳转或重新刷新时，执行 `void(0)` 能确保表达式求值结果为 `undefined`，浏览器不会导航离开当前页。

图5：开发场景与技术选型决策流

总结

回顾核心问题：“为什么 JS 开发中推荐用 void 0 代替 undefined？”：

安全性保证：undefined 并非保留关键字，局部作用域内存在被声明与遮蔽的可能；而 void 0 是一元表达式，规范层面强制求值为纯正且不可篡改的原始 undefined。
体积轻量化：void 0 比 undefined 节省 3 个字符，是构建压缩器与底层通用类库的标准实现。

在现代日常业务开发中，开发者应当优先享受现代语法（TypeScript、ESLint、可选链）带来的可读性与高维护性，将 void 0 的转换交给构建管道；而在需要极致防御与运行兼容的底层库开发中，void 0 依然是最值得信赖的安全护城河。