我要提出第三个建议，谷歌闭包编译器(也是闭包Linter)。你可以在这里在线试用。

闭包编译器是一个让JavaScript下载和运行更快的工具。它是一个真正的JavaScript编译器。它不是从源语言编译到机器代码，而是从JavaScript编译到更好的JavaScript。它解析你的JavaScript，分析它，删除死代码，重写并最小化剩下的代码。它还检查语法、变量引用和类型，并警告常见的JavaScript陷阱。

(编辑) 以下答案经过编辑。我把下面的原始答案留给上下文(否则这些评论就没有意义了)。

当这个问题最初被问到时，JSLint是JavaScript的主要检测工具。JSHint是JSLint的一个新分支，但还没有从原来的分叉。

从那以后，JSLint基本上保持了静态，而JSHint已经发生了很大的变化——它抛弃了许多JSLint中比较对立的规则，增加了大量的新规则，并且总体上变得更加灵活。另外，另一个工具ESLint现在也可用了，它更灵活，有更多的规则选项。

在我最初的回答中，我说过你不应该强迫自己坚持JSLint的规则;只要您了解它为什么抛出警告，您就可以自己判断是否要更改代码来解决警告。

从2011年开始，JSLint的规则集非常严格，这是一个合理的建议——我看到很少有JavaScript代码集可以通过JSLint测试。然而，随着JSHint和ESLint工具中更实用的规则可用，尝试让您的代码零警告地通过它们是一个更现实的命题。

可能偶尔还会有linter抱怨您故意做的事情的情况——例如，您知道应该总是使用===，但只有这一次，您有一个很好的理由使用==。但即使这样，使用ESLint，你也可以选择在有问题的行周围指定ESLint -disable，这样你仍然可以通过零警告的lint测试，其余的代码都遵守规则。(只是不要经常做这样的事情!)

[原答案如下]

务必使用JSLint。但不要对结果和修复它所警告的一切耿耿于心。它将帮助您改进代码，并帮助您发现潜在的错误，但并不是JSLint抱怨的所有问题都变成了真正的问题，所以不要觉得您必须在没有任何警告的情况下完成这个过程。

几乎任何长度或复杂的Javascript代码都会在JSLint中产生警告，无论它写得有多好。如果你不相信我，试着通过它运行一些流行的库，比如JQuery。

一些JSLint警告比其他警告更有价值:了解哪些警告需要注意，哪些警告不那么重要。每个警告都应该考虑，但不要觉得必须修改代码来清除任何给定的警告;你完全可以看一看代码，然后觉得自己满意;有时候，JSlint不喜欢的事情实际上是正确的事情。

几个星期前我也有同样的问题，当时我正在评估JSLint和JSHint。

与这个问题的答案相反，我的结论不是:

务必使用JSLint。

Or:

如果您正在为自己或团队寻找一个非常高的标准，JSLint。

因为你可以在JSHint和JSLint中配置几乎相同的规则。所以我认为你所能实现的规则并没有太大的不同。

因此，选择一个而不是另一个的原因更多是政治上的，而不是技术上的。

我们最终决定使用JSHint，原因如下:

似乎比JSLint更可配置。 看起来更像是社区驱动的，而不是一个人的表演(不管这个男人有多酷)。 JSHint比JSLint更符合我们的代码风格OOTB。

还有另一个正在开发的替代方案- JSCS - JavaScript代码风格:

JSCS是一种代码风格检测器，用于以编程方式强制执行您的风格 指南。您可以使用over为您的项目详细配置JSCS 150条验证规则，包括流行风格指南中的预设 jQuery, Airbnb，谷歌等。

它带有多个预设，您可以通过简单地在.jscsrc配置文件中指定预设并自定义它-覆盖，启用或禁用任何规则来进行选择:

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

还有为流行编辑器构建的插件和扩展。

还看到:

完美的代码，零努力

我要提出第三个建议，谷歌闭包编译器(也是闭包Linter)。你可以在这里在线试用。

闭包编译器是一个让JavaScript下载和运行更快的工具。它是一个真正的JavaScript编译器。它不是从源语言编译到机器代码，而是从JavaScript编译到更好的JavaScript。它解析你的JavaScript，分析它，删除死代码，重写并最小化剩下的代码。它还检查语法、变量引用和类型，并警告常见的JavaScript陷阱。

博士TL;

如果您正在为自己或您的团队寻找一个非常高的标准，请使用JSLint，但请记住，它不一定是标准，只是一个标准，其中一些标准教条地来自Doug Crockford。

如果您想要更灵活一点，或者您的团队中有一些老专家不接受JSLint的观点，或者经常在JavaScript和其他c家族语言之间来回切换，请尝试JSHint。

完整版

有两篇文章解释了JSHint存在的原因:

JSHint: JSLint的一个社区驱动的分支 为什么我把JSLint分叉到JSHint

JSLint背后的理念是它是社区驱动的，而不是crockford驱动的。JSHint通常对JSLint坚持的一些风格和次要语法意见更宽容(或者至少是可配置的或不确定的)。

例如，如果你认为两者都是1。和2。下面是很好的，或者如果你想用1中的一个或多个来编写代码。在2中没有的方面。， JSHint是给你的。如果你认为2。是唯一正确的选择，使用JSLint。我相信还有其他不同之处，但这里突出了一些。

从盒子里传递JSHint - JSLint失败 (函数(){ “使用严格的”; Var x=0, y=2; 函数add(val1, val2){ 返回val1 + val2; ｝ var z; For (var i=0;我< 2;我+ +){ Z = add(y, x+i); ｝ }) (); 同时传递JSHint和JSLint (函数(){ “使用严格的”; Var x = 0, y = 2, i, z; 函数add(val1, val2) { 返回val1 + val2; ｝ For (i = 0;I < 2;I += 1) { Z = add(y, x + i); ｝ } ());

我发现JSLint代码在视觉上更吸引人。我唯一不同意的特性是它讨厌在一个函数中声明多个var，讨厌for-loop var I = 0声明，以及对函数声明的一些空格强制。

A few of the whitespace things that JSLint enforces are not necessarily bad but are just out of sync with some pretty standard whitespace conventions for other languages in the family (C, Java, Python, etc.) often followed as conventions in Javascript as well. Since I'm writing in various of these languages throughout the day and working with team members who don't like Lint-style whitespace in our code, I find JSHint to be a good balance. It catches legitimate bugs and very badly formed code, but doesn't bark at me like JSLint does (sometimes, in ways I can't disable) for the stylistic opinions or syntactic nitpicks that I don't care for.

很多好的库都不能使用Lint，这对我来说证明了JSLint只是推出一个版本的“好代码”(这确实是好代码)的想法是有道理的。但是，同样的库(或其他好的库)可能也不具备Hint'able，因此，touché。