Lodash 92M周下载量背后：97%体积压缩的替代者来了

2024年还在用Lodash的新项目，相当于2024年买燃油新车——不是不能用，是有更好的选择你却不知道。

npm周下载量92M的Lodash，这个数字看着吓人，实则水分不小。Toss团队在2024年推出的es-toolkit，周下载量已经冲到850万，Storybook、Recharts、ink、CKEditor这些生产级项目全切过去了。差距在哪？打包体积97%的缩减，从Lodash的60KB+压到2KB左右。

Core Web Vitals（核心网页指标）现在直接挂钩搜索排名， bundle size不是美学问题，是业务问题。es-toolkit的tree-shaking做得干净，你import一个debounce，最终包里就这一个函数，不会拖进来半套工具库。

速度差2-3倍，不是优化出来的，是重写出来的

benchmark数据上，es-toolkit比Lodash快2-3倍。这不是算法优化，是前提条件变了——Lodash的代码要兼容IE时代的运行时，es-toolkit只认现代JS引擎。相当于一个背着历史包袱，一个轻装上阵。

TypeScript支持是另一道分水岭。Lodash的类型定义靠@types/lodash维护，和源码分开迭代，运行时和编译时偶尔对不上号。es-toolkit的类型和实现同仓库，isNotNil这种type guard直接内置，不用自己写断言。

迁移成本被压得极低。es-toolkit/compat层让你渐进式替换，Vite用户更省事，vite-plugin-es-toolkit自动改写import路径。测试覆盖率100%，不是"我们认为稳定"，是CI里每一行都被跑过。

那Lodash的92M下载量到底是谁在用

拆开看，72M是lodash本体，加上lodash-es约92M。但这里面大量是传递依赖——你装了个老工具库，它依赖Lodash，你的node_modules里就多了一份。直接调用的比例在下降，存量项目的惯性在维持数字。

维护老代码库的团队，熟悉的API本身就是资产。Lodash的文档厚度、边缘case处理、社区问答沉淀，都是切换成本。问题是：新项目为什么要主动跳进这个成本？

ES2024+的原生能力已经填掉不少坑。以前用_.isArray是因为typeof array === 'object'太蠢，现在Array.isArray原生可用。库的存在需要重新justify自己的价值，而不是默认被需要。

2026年选工具库的三条新规则

第一，TypeScript支持必须是first-class，不能是外挂的类型定义。第二，bundle size要可审计，CWV分数会反馈到业务指标上。第三，性能基准要针对现代引擎， backwards compatibility不再是美德，是债务。

es-toolkit符合全部三条，所以850万周下载量不是 hype，是生产环境的投票。Storybook这种被数百万项目依赖的工具链切过去，相当于给整个行业做了尽职调查。

还在用Lodash的新项目，相当于2024年买燃油新车——不是不能用，是有更好的选择你却不知道。而那个"更好的选择"，安装命令只有一行：npm install es-toolkit。

你的新项目启动时，package.json里第一个工具库会写什么？