es-toolkit：用现代 JavaScript 重写 lodash，体积减少 97% 的实用库
一个现代 JavaScript 实用程序库，速度提高了 2-3 倍，体积缩小了 97%，这是对 lodash 的重大升级。
秒懂
- 它是什么？
- es-toolkit 是一个 TypeScript 编写的 JavaScript 工具库，宣称性能是 lodash 的 2 到 3 倍，体积最多减少 97%，并提供完整的 lodash 兼容层。本文基于其 README 和仓库信息，分析它的设计、用法、限制和适用场景。
- 适合谁用？
- es-toolkit 适合那些已经在使用 lodash 但希望减小打包体积、提升运行时性能的现代 JavaScript 项目，尤其是使用 TypeScript 和构建工具支持 tree shaking 的环境。如果你的项目依赖 lodash 的某些边缘行为或深度嵌套的兼容特性，es-toolkit/compat 可能无法 100% 覆盖，迁移前需要针对你使用的每个函数做单元测试。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 3 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
lodash 的现代替代者，解决包体积和性能问题
lodash 是 JavaScript 生态中最常见的工具库，但它的包体积和运行效率在当代前端项目中逐渐成为负担。es-toolkit 的目标就是用现代 JavaScript 特性重写这些工具函数，宣称在主流环境中性能提升 2 到 3 倍，同时通过 tree shaking 将代码体积减少最多 97%。这个库由韩国金融科技公司 Viva Republica 开发，目前被 Storybook、Recharts、ink 和 CKEditor 等项目采用。它主要面向那些已经使用 lodash，但希望优化打包结果和运行时性能的开发者，尤其是使用 TypeScript 的项目。
核心机制：现代实现加 tree shaking
es-toolkit 的性能优势来自对每个函数的重写，而不是简单的包装。它利用现代 JavaScript 引擎的特性，比如更快的数组方法、更高效的对象遍历方式，并避免了 lodash 中为了兼容旧环境而保留的冗余分支。同时，库本身按模块组织，每个函数都是独立的导出，构建工具可以只打包实际用到的部分。README 中的示例展示了 chunk 和 debounce 的基本用法，代码风格与 lodash 几乎一致。这种设计让开发者可以无痛切换，但真正的性能提升取决于你的运行时环境和具体函数。
安装与基本用法：npm 和 JSR 双渠道
es-toolkit 可以通过 npm 安装，包名为 es-toolkit，同时也发布在 JSR 上，包名为 @es-toolkit/es-toolkit。安装后，你可以直接从 'es-toolkit' 导入函数，例如 import { chunk, debounce } from 'es-toolkit'。README 给出了一个 debounce 的示例，调用 debouncedLog('Hello, world!') 会延迟执行。chunk 函数将数组按指定大小分组，输出 [[1, 2], [3, 4], [5, 6]]。这些用法与 lodash 几乎相同，降低了迁移成本。
兼容层 es-toolkit/compat：无缝替换 lodash 的代价
为了简化迁移，es-toolkit 提供了 es-toolkit/compat 子路径，目标是完全兼容 lodash 的 API。这意味着你可以直接替换 import 语句，而无需修改业务代码。但兼容层并非免费，它可能包含 lodash 中的一些非标准行为，或者为了兼容而牺牲部分性能。README 没有详述兼容层的实现细节，但你可以预期，对于大多数常用函数，行为是一致的，但如果你依赖 lodash 的某些边缘特性，比如深路径字符串操作或特定的参数顺序，可能需要额外验证。
类型系统与类型守卫
es-toolkit 使用 TypeScript 编写，内置了类型定义，并且宣称类型简单而健壮。它还提供了一些实用的类型守卫，比如 isNotNil，用于判断值不是 null 或 undefined。这些类型守卫可以帮助你在 TypeScript 中缩小类型范围，减少重复的类型断言。对于 TypeScript 项目来说，这比 lodash 需要额外安装 @types/lodash 要方便得多。不过，类型定义的覆盖范围是否完全等同于 lodash 的复杂泛型，README 没有明确说明，如果你使用高度泛型的代码，可能需要检查类型推断是否一致。
AI 集成：一个新颖但非核心的附加功能
es-toolkit 还提供了 Agent Skills，用于 AI 编程工具，如 Claude Code、Cursor 和 Copilot。你可以通过 npx skills add toss/es-toolkit 安装，或者在 Claude Code 中通过插件市场添加。这看起来像是为了吸引 AI 辅助开发者的额外功能，但 README 没有详细说明这些 skills 具体提供什么能力。对于大多数开发者来说，这并非核心卖点，但如果你使用 AI 编程工具，可能会感兴趣。
局限性与适用边界
es-toolkit 并非没有短板。首先，它的性能提升和体积减少数据来自官方页面，但实际效果取决于你的构建工具和运行时。其次，兼容层虽然宣称完整，但 lodash 的 API 非常庞大，某些冷门函数可能缺失或行为不一致。如果你需要支持旧浏览器，es-toolkit 的现代实现可能无法直接运行，需要额外的 polyfill。另外，100% 测试覆盖率是一个强声明，但测试覆盖不等于行为完全兼容，尤其对于 lodash 这样复杂的库。因此，在迁移前，你应该针对自己使用的每个函数编写测试。
替代方案：lodash 与 es-toolkit 的取舍
最直接的替代方案就是 lodash 本身。lodash 的优势在于其 API 的稳定性和广泛的兼容性，它已经存在多年，被无数项目验证过。但它的缺点是体积大，且 tree shaking 支持不佳，即使只使用几个函数，打包后也可能包含大量代码。另一个替代方案是使用 lodash-es，它提供了 ES module 版本，可以更好地 tree shaking，但内部实现仍然是旧的。es-toolkit 则从零开始，用现代语法重写，因此体积和性能都更优。如果你追求极致的包体积和现代环境下的性能，es-toolkit 是更好的选择；如果你需要最大限度的兼容性和成熟度，lodash 仍然可靠。
编辑结论
es-toolkit 适合那些已经在使用 lodash 但希望减小打包体积、提升运行时性能的现代 JavaScript 项目，尤其是使用 TypeScript 和构建工具支持 tree shaking 的环境。如果你的项目依赖 lodash 的某些边缘行为或深度嵌套的兼容特性，es-toolkit/compat 可能无法 100% 覆盖，迁移前需要针对你使用的每个函数做单元测试。如果你追求极致的 API 稳定性或需要支持非常老的浏览器，那么 lodash 本身可能更稳妥。建议先查看 es-toolkit.dev 的兼容性列表，确认你依赖的函数是否在 compat 中，并运行你的测试套件验证行为一致。
社区笔记