是时候给 lodash 放个假了：4 个更轻更快的现代替代方案

在 ES5 时代，lodash 几乎是前端工程的“标配”。
深拷贝、去重、防抖、节流……一个 _，就能抹平浏览器差异，少写成百上千行工具代码。

但问题是：时代变了。

ES6+ 原生能力全面进化，Array.prototype、Object.*、Promise、Map / Set、structuredClone 已经覆盖了大量 lodash 的核心场景。继续在新项目里 npm i lodash，反而有点“背着历史包袱前行”的味道。

如果你的项目还在用 lodash，不妨花 5 分钟认识下面 4 个最强替代方案。
它们不是来“取代信仰”，而是站在现代 JS 基础设施上，把同样的事做得 更轻、更快、更友好。

1️⃣ lodash-es：最小成本的官方升级方案

定位：lodash 的官方 ESM 分支
一句话总结：API 完全一致，只是换成 ES Module

为什么选它？

• 体积直接腰斩
  全量从约 24 kB → 12 kB，Tree-Shaking 后还能再瘦一圈
• 迁移成本几乎为 0
  全局把 lodash 替换成 lodash-es，老代码、老单测一行不动
• 老项目友好
  浏览器下限依然是 IE11，对历史系统非常安全

适合谁？

• 已经深度依赖 lodash
• 想先“瘦身”，暂时不想改写工具函数
• 大型、稳定期项目

👉 一句建议：如果你现在什么都不想改，只想体积小一点，选它。

2️⃣ es-toolkit：无痛超速版 lodash

定位：全新实现 + 100% 兼容层
一句话总结：今天卸载 lodash，明天照常上线需求

核心优势

• 镜像级兼容
  提供 es-toolkit/compat 子包，函数签名与 lodash 高度一致
  官方 codemod 可 90% 自动替换
• 又快又小
  性能提升 2–3 倍，体积减少 70%
  已有团队在 24 小时内完成全量迁移
• TypeScript 体验极佳
  原生 TS、零 anyget(obj, 'a.b.c.d') // 返回类型：string | undefined 类型推断能精确到第四层

适合谁？

• 正在做 现代化重构
• 对性能和类型安全有要求
• 想摆脱 lodash，但不想重写大量代码

👉 一句建议：这是目前最“平衡”的 lodash 替代品。

3️⃣ Radashi（Radash 社区续命版）：极致性能党首选

定位：零依赖 + ES2020 新算法
一句话总结：为 Edge Function 和冷启动而生

为什么它这么快？

• 性能怪兽
  Benchmark 中普遍 3–7 倍性能提升
  包体积减少 75%
• 类型体验拉满
  零 any，错误优先设计
  tryit / parallel / retry 等高并发工具一把梭
• 社区持续维护
  Radash 官方归档后，Radashi 社区接手
  Nightly 发版 + RFC 公开投票

适合谁？

• Serverless / Edge Function
• 冷启动敏感的应用
• 重视函数式风格与类型安全的团队

👉 一句建议：如果你追求“能快 1ms 是 1ms”，它值得你研究。

4️⃣ moderndash：稳健折中派

定位：保留 lodash API，内部用原生 API 重写
一句话总结：升级但不冒险

它的取舍哲学

• 体积 −70%，性能 ×2–4
• 浏览器下限 ES2020，不再背负远古兼容包袱
• 95% 函数签名一致
  官方 codemod + 自动跑单测
• 只保留 70+ 高频函数
  像 _.iteratee 这种冷门能力直接移除
  学习成本更低，API 更干净

适合谁？

• 想升级 lodash，但害怕改爆
• 代码量大、测试覆盖高的成熟项目
• 团队更偏向“稳”

👉 一句建议：这是“保守派工程师”的安心之选。

📊 快速选型对照表

结语：不是淘汰 lodash，而是升级认知

lodash 并没有“过时”，它只是完成了自己的历史使命。
在 ES6+、Tree-Shaking、TypeScript、Edge Runtime 成为主流的今天，我们有了更好的选择。

如果你正在新建项目，真的可以不再默认安装 lodash；
如果你维护老项目，也完全可以 循序渐进地替换。

技术不是推倒重来，而是用更合适的工具，走更远的路。

下一次写 npm i lodash 之前，不妨先问一句：
“我真的还需要它吗？”