为什么有人会比其他人更喜欢lodash.js或underscore.js实用程序库？
Lodash似乎是下划线的替代品，下划线的使用时间更长。
我认为两者都很出色，但是我对它们的工作方式还不够了解，无法进行有根据的比较，并且我想更多地了解差异。
Answers:
我创建Lo-Dash的目的是为数组，字符串，对象和arguments对象1提供更一致的跨环境迭代支持。此后，它已成为Underscore的超集，提供更一致的API行为，更多功能（如AMD支持，深度克隆和深度合并），更全面的文档和单元测试（在Node，Ringo，Rhino，Narwhal，PhantomJS中运行的测试）和浏览器），可为大型数组/对象迭代提供更好的整体性能和优化，并通过自定义版本提供更大的灵活性和模板预编译实用程序。
由于Lo-Dash的更新频率比Underscore更新的频率高，因此提供了一个内部lodash underscore版本了以确保与Underscore的最新稳定版本兼容。
有一次我什至获得了推送访问权限 Underscore的，部分原因是Lo-Dash负责提出30多个问题。Underscore v1.4.x +中的着陆错误修复，新功能和性能提升。
另外，至少有3个Backbone样板默认包含Lo-Dash，并且Back-Bone的官方文档中现在提到了Lo-Dash 。
查看Kit Cambridge的帖子，向Lo-Dash说“你好”，以深入了解Lo-Dash和Underscore之间的区别。
脚注：
arguments对象的支持不一致。在较新的浏览器中，Underscore方法将忽略数组中的孔，“ Objects”方法将迭代arguments对象，将字符串视为类似于数组的方法，并且方法将正确地迭代函数（忽略其“ prototype”属性）和对象（迭代阴影的属性，例如“ toString”和“ valueOf”），而在较旧的浏览器中则不会。此外，Underscore方法（如_.clone保留数组中的孔），而其他方法_.flatten则不保留。Lo-Dash受到下划线的启发，但如今已成为卓越的解决方案。您可以进行自定义构建，具有更高的性能，支持AMD并具有出色的额外功能。在jsperf上查看此Lo-Dash vs Underscore 基准测试。.. 关于lo-dash的真棒帖子：
使用集合时，最有用的功能之一是速记语法：
var characters = [
{ 'name': 'barney', 'age': 36, 'blocked': false },
{ 'name': 'fred', 'age': 40, 'blocked': true }
];
// using "_.filter" callback shorthand
_.filter(characters, { 'age': 36 });
// using underscore
_.filter(characters, function(character) { return character.age === 36; } );
// → [{ 'name': 'barney', 'age': 36, 'blocked': false }]（摘自lodash docs）
如果像我一样，您期望下划线和lodash之间的用法差异列表，那么有一个从下划线迁移到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)。_.indexOf带第三个参数的下划线undefined是Lodash_.indexOf_.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
（例如，下划线_.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
（即_.head(array, 2)在下划线是_.take(array, 2)在Lodash）
除了John的回答，并阅读lodash（我迄今认为下划线是“我也很想强调”），并查看性能测试，阅读源代码和博客文章，这些使lodash的几点这些要比下划线要好得多：
这不关乎速度，而是关乎速度的一致性（？）
如果查看下划线的源代码，您会在前几行中看到下划线是许多功能的本机实现的基础。尽管在理想的情况下，这本来是一种更好的方法，但是如果您看一下这些幻灯片中提供的一些性能链接，则不难得出这样的结论，即这些“本机实现”的质量在很多浏览器中都不同，浏览器。Firefox在某些功能上非常快速，在某些Chrome中占主导地位。（我想在某些情况下IE也将占主导地位）。我认为最好是使用跨浏览器性能更一致的代码。
一定要早点阅读该博客文章，而不是为了它而相信它，而是通过运行基准来自己判断。我现在被惊呆了，看到即使在简单的原生功能（例如
Array.everyChrome）中，lodash的执行速度也比下划线快100-150％！
该临时演员lodash也非常有用。
这是2014年，并且为时已晚。我仍然认为我的观点是正确的：
恕我直言，这一讨论不合比例。引用上述博客文章：
大多数JavaScript实用程序库（例如Underscore，Valentine和wu）都依赖于“本机优先双重方法”。这种方法更喜欢本机实现，只有在不支持本机等效功能时，才使用原始JavaScript。但是jsPerf揭示了一个有趣的趋势：遍历数组或类似数组的集合的最有效方法是完全避免本机实现，而选择简单的循环。
好像“简单循环”和“原始Javascript”比Array或Object方法实现更原生。哎呀...
有一个单一的事实来源当然会很好，但事实并非如此。亲爱的，即使有人告诉您，也没有香草神。对不起。真正成立的唯一假设是，我们都在编写旨在在所有主要浏览器中都表现良好的Javascript代码，因为他们知道所有这些浏览器都有相同的事物的不同实现。温和地说，这是一个应付的ch子。但这是前提，无论您是否喜欢。
也许你们所有人都在从事需要微调性能的大型项目，所以您现在可以在每秒列表上真正看到850,000（下划线）与2,500,000（lodash）迭代之间的差异！
我不是一个。我的意思是，我在必须解决性能问题的项目中工作，但是这些问题从未解决过，也不是由Underscore或Lo-Dash引起的。而且，除非我掌握了实现和性能的真正差异（我们现在正在谈论C ++），让我们说一个遍历可迭代对象（对象或数组，稀疏与否！）的循环，否则我不会为任何问题所困扰根据已经被接受的基准平台的结果进行声明。
它只需要更新一次，比如说Rhino，就可以以一种方式让Array方法的实现着火，这种方式不会让任何一个“中世纪循环方法表现得更好，永远如此，而牧师不会”就这样一个简单的事实争论自己： FF中的突然排列方法比他/她自以为是的头脑快得多。伙计，您只是不能通过欺骗运行时环境来欺骗运行时环境！推广时考虑一下...
你的腰带
... 下次。
因此，保持相关性：
选择最适合您需求的方法。照常。我宁愿随时随地对实际实现进行回退，也不要选择任何固执己见的运行时作弊手段，但如今看来，这仍然是个问题。坚持使用http://developer.mozilla.com和http://caniuse.com之类的优质资源，一切都会好起来的。
Array.from他们的信息，他们甚至可能都不知道应该怎么做。JS“工具带”人们似乎过于关注推广自己的通用变通方法，以至于他们往往忘记这样做，实际上是在稀释标准化过程。不需要功能不会对浏览器“制造商”造成压力。有趣的事实：的4级主要的浏览器2是基于开源项目（1，2）。
我同意这里所说的大多数内容，但是我只想指出一个支持underscore.js的论点：库的大小。
特别是在您开发要主要在移动设备上使用的应用或网站的情况下，所得捆绑包的大小以及对启动或下载时间的影响可能会发挥重要作用。
为了进行比较，这些大小是运行离子服务后我在source-map-explorer中注意到的大小：
lodash: 523kB
underscore.js: 51.6kb2020年2月编辑：
人们可以使用BundlePhobia检查的当前大小罗短跑和下划线
source-map-explorer after running ionic serve
不知道这是否是OP的意思，但是我遇到了这个问题，因为我在搜索从下划线迁移到lodash时必须牢记的问题列表。
如果有人发布一篇包含此类差异的完整列表的文章，我将不胜感激。让我从我艰难学习的东西开始（即，使我的代码在生产中爆炸的东西：/）：
_.flatten下划线默认是深的，您必须将true作为第二个参数传递以使其变浅。在lodash中，默认情况下它是浅的，而将true作为第二个参数传递将使其变深！:)_.last下划线中的in接受第二个参数，该参数告诉您要多少个元素。在lodash没有这样的选项。您可以使用.slice_.first （同一期）_.template下划线中的可以有多种使用方式，其中一种是提供模板字符串和数据并HTML取回（或者至少是一段时间前的工作方式）。在lodash其中，您将收到一个函数，然后应将其提供给数据。_(something).map(foo)在下划线下工作，但在lodash中我不得不将其重写为_.map(something,foo)。也许那只是一个TypeScript问题_(something).map(foo).value()。
http://benmccormick.org/2014/11/12/underscore-vs-lodash/
Ben McCormick的最新文章将两者进行了比较：
Lo-Dash的API是Underscore的超集。
引擎盖下的[Lo-Dash]已被完全重写。
Lo-Dash绝对不比Underscore慢。
Lo-Dash添加了什么？
- 可用性改进
- 额外功能
- 绩效提升
- 链接的简写语法
- 自定义构建仅使用您需要的内容
- 语义版本控制和100％的代码覆盖率
我只是发现一个差异对我来说很重要。lodash的的非下划线兼容的版本_.extend()确实不拷贝过来的类级定义的属性或方法。
我已经在CoffeeScript中创建了一个Jasmine测试，以证明这一点：
https://gist.github.com/softcraft-development/1c3964402b099893bd61
幸运的是，lodash.underscore.js保留了Underscore复制所有内容的行为，这对我来说是理想的行为。
