Lodash下载量暴跌97%背后：韩国团队用2KB代码掀桌了

2024年，韩国金融科技公司Toss的一支小团队发布了一个工具库。两年后，它的周下载量冲到850万，GitHub星标破万。而Lodash的周下载量虽然还有7200万，但业内都知道——那数字里大部分是"遗产"。

真正在用Lodash写新代码的人，正在以肉眼可见的速度消失。

97%的体积差，怎么算出来的

es-toolkit的打包体积约2KB。Lodash即便用lodash-es版本，完整引入也在70KB以上。这不是简单的"优化"，是代际差距。

Tree-shaking（树摇优化）在这里起了决定性作用。es-toolkit的每个函数都是独立模块，你引入debounce，打包结果就只有debounce。Lodash的历史包袱在于：它的很多函数内部互相依赖，摇不干净。

Google的Core Web Vitals（核心网页指标）已经把首屏加载时间算进搜索排名。对电商、内容站点来说，70KB和2KB的区别，可能就是"用户留下来"和"用户关掉标签页"的区别。

性能基准测试更夸张：es-toolkit比Lodash快2-3倍。Toss团队没有兼容IE的包袱，直接针对现代JS引擎重写实现。Lodash的不少代码还在为2015年前的运行时做妥协。

Storybook、Recharts、ink、CKEditor——这些项目的共同点是：对TypeScript有硬性要求，对包体积极度敏感。它们的选择不是跟风，是算账之后的理性决策。

TypeScript的"类型漂移"陷阱

Lodash的类型定义在@types/lodash包里，由社区维护，和主仓库不同步。这意味着：你写的代码类型检查通过了，运行时可能报错。或者反过来，运行时正常，类型系统却红一片。

es-toolkit的类型和实现源码在同一个仓库，同一次提交。isNotNil这类类型守卫函数直接内置，不用自己写冗长的类型收窄逻辑。

API设计几乎和Lodash一致。import { debounce, groupBy } from 'es-toolkit'，迁移成本趋近于零。团队还做了es-toolkit/compat层，专门给想逐步替换的人用。

Vite用户有更懒的办法：vite-plugin-es-toolkit自动重写你的Lodash导入。配置一行，存量代码无痛迁移。

测试覆盖率100%。这个数字在开源工具库里不多见，意味着维护者把可靠性当成底线而非卖点。

7200万下载量的水分

Lodash的7200万周下载量（加上lodash-es约9200万）看起来仍是巨无霸。但拆开看，大量是"传递依赖"——你装了一个工具，它依赖Lodash，你自己根本没直接引用。

这种数字会自我强化：包越流行，越容易被其他包依赖；被依赖越多，下载量越高，显得越流行。但2026年的新项目选型，这个循环正在被打破。

维护存量代码的团队，继续使用Lodash是合理选择。API熟悉、文档完善、边缘场景处理成熟——切换的摩擦成本可能超过收益。

但新项目没有历史包袱。当es-toolkit能提供几乎相同的API，体积差两个数量级，类型零漂移，性能还更快，"继续用Lodash"需要额外 justification（正当理由）。

韩国Toss团队的身份也值得玩味。这不是硅谷巨头的产品，是一家亚洲金融科技公司的内部工具开源化。类似的故事在2020年代反复上演：Vercel的Turbopack、字节跳动的Rspack、阿里的Midway——基础设施的创新中心正在分散。

ES2024+吃掉多少工具库

原生JavaScript的进化是另一股推力。ES2024+填补了大量曾经需要库来补的缺口：原生groupBy提案进入Stage 3，Promise.withResolvers标准化，Array.prototype.toSorted等不可变方法落地。

工具库的生存空间被压缩到两个方向：一是polyfill（填充）最新标准，二是做标准不会做的性能优化和类型增强。es-toolkit的定位是后者。

它的竞争对手不止Lodash。Radash、Remeda、Ramda都在分同一块蛋糕。但es-toolkit的增速最快，部分原因是Toss的商业背景给了它持续维护的确定性——不像个人维护项目，哪天维护者去大厂搬砖就停滞了。

100%测试覆盖率、Vite官方插件、Storybook等头部项目的背书，这些组合起来构成了一种"生产就绪"的信号。开发者选型时，这种信号比功能列表更有说服力。

迁移工具链的完善降低了试错成本。你可以先装compat层，验证无误后再切完整版。整个过程不需要重写业务逻辑，只是改import路径。

韩国开发者在GitHub上的存在感近年明显上升。从es-toolkit到toss/es-hangul（韩文处理库），Toss的开源策略是把内部打磨过的工具反哺社区，同时建立技术品牌。这和Vercel、Vercel（应为Vercel模式）的路径相似，只是起点在首尔而非旧金山。

工具库战争的终局通常不是"一个吃掉所有"，而是分层稳定。Lodash会变成类似jQuery的存在：不再时髦，但存量巨大，维护到2030年代没问题。es-toolkit们争夺的是新项目的默认选项——这个位置的复利效应更强。

你现在打开一个新项目，会为了团队熟悉度继续装Lodash，还是愿意花两小时验证es-toolkit的迁移成本？