我创建了 Lodash 来为数组、字符串、对象和arguments对象¹提供更一致的跨环境迭代支持。它已成为 Underscore.js 的超集，提供更一致的 API 行为、更多功能（如 AMD 支持、深度克隆和深度合并）、更全面的文档和单元测试（在Node.js、RingoJS、Rhino 中运行的测试）、Narwhal、PhantomJS和浏览器）、更好的整体性能和大型数组/对象迭代的优化，以及自定义构建和模板预编译实用程序的更大灵活性。

由于 Lodash 的更新频率高于 Underscore.js，因此提供了一个lodash underscore构建版本以确保与Underscore.js的最新稳定版本兼容。

有一次，我什至获得了对 Underscore.js 的推送访问权限，部分原因是 Lodash 负责提出 30 多个问题；在 Underscore.js v1.4.x+ 中登陆错误修复、新功能和性能提升。

此外，至少有三个Backbone.js样板默认包含 Lodash，现在 Backbone.js 的官方文档中提到了 Lodash 。

查看 Kit Cambridge 的帖子，向 Lo-Dash 说“你好”，更深入地了解 Lodash 和 Underscore.js 之间的差异。

脚注：

1. Underscore.js 对数组、字符串、对象和arguments对象的支持不一致。在较新的浏览器中，Underscore.js 方法忽略数组中的漏洞，“Objects”方法迭代arguments对象，字符串被视为类数组，并且方法正确迭代函数（忽略它们的“prototype”属性）和对象（迭代像“toString”这样的阴影属性" 和 "valueOf")，而在较旧的浏览器中则不会。此外，Underscore.js 方法，例如_.clone，保留数组中的空洞，而其他方法_.flatten则不会。

Lodash 的灵感来自 Underscore.js，但现在它是一个卓越的解决方案。您可以进行自定义构建，获得更高的性能，支持 AMD 并拥有出色的额外功能。检查jsperf上的 Lodash 与Underscore.js 基准测试，以及...这篇关于 Lodash 的精彩文章：

当您使用集合时，最有用的功能之一是速记语法：（
尽管 Underscore 现在也支持此语法）

var characters = [
  { 'name': 'barney', 'age': 36, 'blocked': false },
  { 'name': 'fred',   'age': 40, 'blocked': true }
];

// Using "_.filter" callback shorthand
_.filter(characters, { 'age': 36 });

// Using Underscore.js
_.filter(characters, function(character) { return character.age === 36; } );

// → [{ 'name': 'barney', 'age': 36, 'blocked': false }]

（取自Lodash 文档）

如果像我一样，您期待 Underscore.js 和 Lodash 之间的使用差异列表，那么这里有一个从 Underscore.js 迁移到 Lodash 的指南。

这是后代的当前状态：

• 下划线_.any是 Lodash_.some
• 下划线_.all是 Lodash_.every
• 下划线_.compose是 Lodash_.flowRight
• 下划线_.contains是 Lodash_.includes
• 下划线_.each不允许通过返回退出false
• 下划线_.findWhere是 Lodash_.find
• _.flatten默认下划线很深，而 Lodash 很浅
• 下划线_.groupBy支持传递的参数的iteratee (value, index, originalArray)，而在Lodash，对于iteratee_.groupBy仅通过一个参数：(value)。
• Underscore.js_.indexOf与第三个参数undefined是Lodash_.indexOf
• Underscore.js_.indexOf与第三个参数true是Lodash_.sortedIndexOf
• 下划线_.indexBy是 Lodash_.keyBy
• 下划线_.invoke是 Lodash_.invokeMap
• 下划线_.mapObject是 Lodash_.mapValues
• 下划线_.max结合了 Lodash _.max&_.maxBy
• 下划线_.min结合了 Lodash _.min&_.minBy
• 下划线_.sample结合了 Lodash _.sample&_.sampleSize
• 下划线_.object结合了 Lodash_.fromPairs和_.zipObject
• _.omit谓词的下划线是 Lodash_.omitBy
• 下划线_.pairs是 Lodash_.toPairs
• _.pick谓词的下划线是 Lodash_.pickBy
• 下划线_.pluck是 Lodash_.map
• 下划线_.sortedIndex结合了 Lodash _.sortedIndex&_.sortedIndexOf
• 下划线_.uniq由iteratee是Lodash_.uniqBy
• 下划线_.where是 Lodash_.filter
• 下划线_.isFinite不对齐Number.isFinite
  （例如在 Underscore.js 中_.isFinite('1')返回true，但false在 Lodash 中）
• 下划线_.matches速记不支持深度比较
  （例如，_.filter(objects, { 'a': { 'b': 'c' } })）
• 下划线 ≥ 1.7 & Lodash_.template语法是
  _.template(string, option)(data)
• Lodash_.memoize缓存Map就像对象
• Lodash 不支持支持context许多方法的论点_.bind
• Lodash 支持隐式链接、惰性链接和快捷方式融合
• Lodash 将其重载的_.head, _.last, _.rest, &拆分_.initial为
  _.take, _.takeRight, _.drop, & _.dropRight
  （即在 Underscore.js_.head(array, 2)中是_.take(array, 2)在 Lodash 中）

除了约翰的回答，阅读 Lodash（我一直认为它是 Underscore.js 的“我也是”），以及查看性能测试、阅读源代码和博客文章之外，还有几点使 Lodash 优于 Underscore.js 的是这些：

1. 这不是关于速度，而是关于速度的一致性（？）

如果您查看 Underscore.js 的源代码，您会在前几行看到 Underscore.js 回退到许多函数的本机实现。尽管在理想的世界中，这本来是一种更好的方法，但如果您查看这些幻灯片中给出的一些性能链接，不难得出结论，即这些“本机实现”的质量与浏览器的差异很大-到浏览器。Firefox 在某些功能上非常快，而在某些 Chrome 中占主导地位。（我想在某些情况下 Internet Explorer 也会占主导地位）。我认为最好选择性能在浏览器间更一致的代码。

一定要早点阅读博客文章，而不是相信它，而是通过运行基准来判断自己。我现在惊呆了，即使在 Chrome等简单的原生函数中，Lodash 的执行速度也比 Underscore.js 快 100-150% Array.every！

2. Lodash 中的附加功能也非常有用。
3. 至于 Xananax 的高度赞成的评论，建议对 Underscore.js 的代码做出贡献：拥有良好的竞争总是更好，不仅可以保持创新，还可以驱使您保持自己（或您的库）处于良好状态。

这是Lodash 之间的差异列表，它的 Underscore.js 构建是您的 Underscore.js 项目的替代品。

在 2014 年，我仍然认为我的观点是成立的：

恕我直言，这个讨论有点过分了。引用上述博客文章：

大多数 JavaScript 实用程序库，例如 Underscore、Valentine 和 wu，都依赖于“本机优先的双重方法”。这种方法更喜欢本机实现，只有在不支持本机等效项时​​才回退到 vanilla JavaScript。但是 jsPerf 揭示了一个有趣的趋势：迭代数组或类数组集合的最有效方法是完全避免本机实现，而是选择简单的循环。

好像“简单循环”和“vanilla Javascript”比数组或对象方法实现更原生。天啊...

拥有单一的真相来源当然很好，但事实并非如此。即使有人告诉你，也没有香草之神，亲爱的。抱歉。唯一真正成立的假设是，我们都在编写旨在在所有主要浏览器中表现良好的 JavaScript 代码，并且知道所有浏览器对相同的事物都有不同的实现。说得客气一点，这是个婊子要应付。但这是前提，不管你喜不喜欢。

也许你们所有人都在从事需要 twitterish 性能的大型项目，以便您现在真正看到每秒列表中 850,000 (Underscore.js) 与 2,500,000 (Lodash) 迭代之间的差异！

我不是。我的意思是，我参与了一些必须解决性能问题的项目，但这些问题从未被 Underscore.js 和 Lodash 解决或导致。除非我掌握了实现和性能（我们现在谈论的是 C++）的真正差异，比如说，一个可迭代对象（对象或数组，稀疏与否！）的循环，我宁愿不要被打扰任何基于已经固执己见的基准平台结果的声明。

它只需要对Rhino进行一次更新，就可以以一种方式将其 Array 方法实现设置为火，而没有一个“中世纪循环方法表现得更好，永远等等”牧师可以围绕一个简单的事实争论他/她的方式突然之间，Firefox 中的数组方法比他/她自以为是的脑残要快得多。伙计，你不能通过欺骗你的运行时环境来欺骗你的运行时环境！推广的时候想想...

你的实用腰带

... 下次。

因此，要保持相关性：

• 如果您在不牺牲原生性的情况下获得便利，请使用 Underscore.js。
• 如果您喜欢使用 Lodash 方便并且喜欢它的扩展功能目录（深拷贝等），并且如果您迫切需要即时性能，并且最重要的是，不要介意在原生 API 胜过自以为是的情况下尽快找到替代方案解决方法。这很快就会发生。时期。
• 甚至还有第三种解决方案。DIY！了解您的环境。了解不一致性。阅读他们（John-David和Jeremy的）代码。不要在无法解释为什么真正需要一致性/兼容性层并增强您的工作流程或提高应用程序性能的情况下使用这个或那个。很可能您的需求可以通过一个您完全能够自己编写的简单polyfill来满足。这两个库都只是加了一点糖的普通香草。他们都在为谁提供最甜的馅饼而争吵。但相信我，最终两者都只是用水做饭。没有香草神，所以不可能没有香草教皇，对吧？

选择最适合您需求的方法。照常。我更喜欢在任何时候对实际实现进行回退，而不是固执的运行时作弊，但即使是现在，这似乎也是一个品味问题。坚持使用http://developer.mozilla.com和http://caniuse.com等优质资源，您会没事的。