手写JS isEmpty函数与Lodash实现的对比分析

在 JavaScript 开发中，判断一个变量是否“为空”（Empty）看似是一项极低门槛的操作，但在复杂业务和极端数据结构面前，它也是最容易引发隐蔽 Bug 的逻辑之一。开发者常常会直觉地使用 !val、Object.keys(val).length === 0 或者直接引入 lodash.isEmpty。然而，在处理数字 0、布尔值 false、ES6 集合容器（Map / Set）以及原型链属性时，不同实现之间的语义分歧与边界陷阱就会暴露无遗。本文将深入拆解 Lodash _.isEmpty 的底层设计逻辑，梳理手写实现中高频踩坑的边界场景，并手把手构建一个高健壮、零外部依赖且契合业务直觉的 isEmpty 纯函数。

一、核心哲学分歧：“容器为空”还是“缺少有效值”

要客观对比手写与 Lodash 的实现差异，首先必须搞清楚二者对“空”的定义基准。这个根本性差异直接决定了函数的返回结果：

• Lodash 的定义基准是“无自身集合元素或可枚举属性”：从泛型容器的视角出发，基本数据类型（如数字、布尔值、Symbol）既不是长度集合，自身也没有字符串形式的可枚举属性，因此在 Lodash 的设计中，_.isEmpty(0) === true、_.isEmpty(false) === true、_.isEmpty(Symbol()) === true。
• 业务开发的直觉基准是“数据未填写或容器无内容”：在表单校验、参数处理与接口交互中，数字 0 通常代表有效的数量或金额，布尔值 false 代表有效的禁用/开关状态。如果直接使用 Lodash，开发者极易误将数字 0 和 false 判定为空，导致表单无法提交或过滤逻辑失真。

二、Lodash _.isEmpty 内部判定流程与源码剖析

在 Lodash 源码中，isEmpty（基于 lodash.isEmpty/index.js）采用严密的分支降级策略。它针对 JavaScript 中多种类数组、原型对象、集合类型做了细致的特判，其内部运行流程可归纳为以下五个关键步骤：

1. Nullish 前置拦截：直接检查 value == null。若值为 null 或 undefined，直接短路返回 true。
2. 类数组（Array-Like）长度检验：检查 isArrayLike(value)。如果目标是数组、字符串、arguments 对象、Buffer 或 TypedArray，直接返回 !value.length。
3. ES6 集合标签比对：通过 getTag(value) 获取内部对象标记。当属于 [object Map] 或 [object Set] 时，返回 !value.size。
4. 原型对象（Prototype）隔离：通过 isPrototype(value) 检查传入的是否为某构造函数的原型对象。若是，则必须排除原型上继承的成员，仅通过 baseKeys 统计其自身挂载的属性数量。
5. 可枚举属性遍历与原始类型兜底：执行 for (var key in value) 并结合 hasOwnProperty.call(value, key)。只要检测到任何一个自身可枚举属性，即返回 false；若无任何自身属性，则返回 true。数字、布尔值、函数等均在此步降级，因其没有自身可枚举属性而返回 true。

三、手写初级实现的四大常见陷阱

很多工程项目中为了减少依赖体积，通常会手写一行辅助函数，例如 const isEmpty = val => !val || !Object.keys(val).length;。这种简化写法在真实场景中存在严重缺陷：

1. Falsy 假值无差别误杀

利用 !val 判断时，JavaScript 中的所有假值（0、""、false、NaN、null、undefined）都会被转换为 true。这使得数字 0 与布尔值 false 无法作为合法数据存活，直接破坏了业务逻辑。

2. Object.keys 的类型盲区与异常

在 ES5 环境中，向 Object.keys() 传入非对象参数（如 Object.keys(null)）会直接抛出 TypeError；虽然 ES6 对此做了静默对象化转换，但对原始数字执行 Object.keys(123) 会得到 []，若直接判断 length === 0，数字同样会被误认为“空”。

3. ES6 Map 与 Set 集合完全穿透

Object.keys() 只能提取对象自身的可枚举属性名，而 Map 和 Set 的元素并不存储为对象的常规属性键。即便执行 const map = new Map([['key', 'value']])，调用 Object.keys(map) 依然返回空数组 []。如果依赖 Object.keys 判断，包含上万条数据的 Map 也会被误判为“空对象”！

4. 原型链属性干扰与 Symbol 遗漏

若使用 for...in 遍历而未添加 Object.prototype.hasOwnProperty 防护，会遍历到原型链上挂载的自定义属性。同时，如果一个对象仅包含 Symbol 属性（例如 { [Symbol('id')]: 1001 }），Object.keys() 无法获取该属性，导致非空对象被判定为空。

下表详细列出了不同实现方式在面对常见测试用例时的具体表现：

四、分层构建：手写生产级健壮的业务 isEmpty

为了兼顾业务直觉与底层类型的鲁棒性，我们可以采用“分层漏斗”的管道化设计思想来手写 isEmpty 函数。从最具体的特征自顶向下进行匹配拦截：

完整代码实现 (TypeScript / JavaScript)

以下是具备生产级容错能力、零外部依赖的高性能纯函数实现：

/**
 * 健壮的业务级判空函数 (isEmpty)
 * 兼顾集合容器与常规输入项判定，符合主流中后台业务开发直觉
 *
 * @param {unknown} value 待检测的任意类型目标值
 * @param {object} [options] 可选配置项
 * @param {boolean} [options.zeroIsEmpty=false] 是否将数字 0 判定为空 (默认 false，即 0 视为有效值)
 * @returns {boolean} 是否为空
 */
function isCustomEmpty(value, options = {}) {
  const { zeroIsEmpty = false } = options;

  // 第 1 步：Nullish 检查 (null 与 undefined)
  if (value === null || value === undefined) {
    return true;
  }

  // 第 2 步：基础标量安全保护 (数字、布尔、BigInt、Symbol)
  if (typeof value === 'boolean') {
    return false; // 布尔值 true/false 均表示有效状态
  }

  if (typeof value === 'number') {
    if (Number.isNaN(value)) {
      return true; // NaN 视为无效空值
    }
    return zeroIsEmpty ? value === 0 : false;
  }

  if (typeof value === 'bigint' || typeof value === 'symbol') {
    return false;
  }

  // 第 3 步：字符串检查 (纯空格字符串可根据业务需求扩展 trim)
  if (typeof value === 'string') {
    return value.trim().length === 0;
  }

  // 第 4 步：线性集合/数组检查
  if (Array.isArray(value)) {
    return value.length === 0;
  }

  // 第 5 步：ES6 Map / Set 集合检查
  if (value instanceof Map || value instanceof Set) {
    return value.size === 0;
  }

  // 第 6 步：特殊引用类型特判 (Date、RegExp、Function)
  if (value instanceof Date) {
    return Number.isNaN(value.getTime()); // 无效日期视为 Empty
  }

  if (value instanceof RegExp || typeof value === 'function') {
    return false; // 函数与正则实例视为有效存在实体
  }

  // 第 7 步：普通对象自身可枚举键及 Symbol 属性扫描
  if (typeof value === 'object') {
    const stringKeys = Object.keys(value);
    if (stringKeys.length > 0) {
      return false;
    }

    // 检查自身是否存在 Symbol 属性
    const symbolKeys = Object.getOwnPropertySymbols(value);
    if (symbolKeys.length > 0) {
      return false;
    }

    return true;
  }

  return false;
}

五、工程化选型与权衡建议

在实际的前端工程或 Node.js 服务端架构中，我们应当如何在手写函数与社区库 lodash.isEmpty 之间进行技术选型？

1. 打包体积与依赖治理 (Bundle Size)

虽然 Lodash 提供了模块化引入形式（如 import isEmpty from 'lodash/isEmpty'），但由于其内部依赖了 getTag、isArrayLike、isBuffer、isArguments、isTypedArray、isPrototype 等十多个内部辅助模块，打包进产物的实际代码体积约为 4KB ~ 5KB (minified)。在对体积高度敏感的移动端 H5、微信小程序或独立微前端 SDK 中，引入整个依赖链条代价较高；而手写实现的纯函数体积不到 0.3KB，且完全零依赖。

2. 业务语义契合度

如果你的场景集中在 用户交互、表单提交、筛选条件重置，手写定制函数远优于 Lodash。Lodash 坚持的“0 为 empty”在业务场景中反而是高频缺陷的源头。采用具备参数保护的手写函数能消除团队成员的心智负担，避免在调用处到处补充 val !== 0 && !isEmpty(val) 这样的防御性补丁。

3. 何时推荐直接使用 Lodash

在以下场景中，推荐直接使用 Lodash 或其 ESM 重构版本（如 lodash-es）：

• 工程已经深度依赖 Lodash 且公共 chunk 已包含该库，无需担心边际打包体积。
• 涉及 Node.js 底层协议层开发，需要深度处理 Buffer、TypedArray、类数组 arguments 等极端底层对象。
• 团队制定了严苛的零自研底层工具规范，统一依托成熟开源生态。

六、总结与落地建议

判断 JavaScript 变量是否为空，核心不在于写出一个多么庞大的工具函数，而在于清晰定义所处上下文对“有效数据”的边界预期。Lodash 追求的是底层泛型数据结构的一致性容器语义，而日常开发追求的是贴近领域逻辑的有效值校验。通过本文梳理的分层检查机制，团队可以在轻量化应用中放心使用定制手写版本，在降低打包开销的同时，彻底杜绝 0 与 false 带来的隐蔽缺陷。