最近，当我遇到此错误时，我正在通过 JSLint 运行我的一些代码。我认为这个错误的有趣之处在于它自动假定所有 == 都应该是 ===。
这真的有意义吗？我可以看到很多你不想比较类型的实例，我担心这实际上会导致问题。
“预期”一词意味着每次都应该这样做......这对我来说没有意义。
【问题讨论】：
myVar == null 检查，是的，很大的变化。 ;^) Crockford 的论点是它使代码的含义更加精确，这很难争论。
标签： javascript jslint
IMO，盲目使用===，而不尝试理解类型转换的工作原理没有多大意义。
关于 Equals 运算符== 的主要恐惧是，取决于比较类型的比较规则会使运算符不可传递，例如，如果：
A == B AND
B == C
并不能真正保证：
A == C
例如：
'0' == 0; // true
0 == ''; // true
'0' == ''; // false
当您比较相同类型的值时，Strict Equals 运算符 === 并不是真正需要的，最常见的示例：
if (typeof foo == "function") {
//..
}
我们比较typeof 运算符的结果，它总是是一个字符串，与一个字符串字面量...
或者当您知道类型强制规则时，例如，检查某事物是否为 null 或 undefinedsomething：
if (foo == null) {
// foo is null or undefined
}
// Vs. the following non-sense version:
if (foo === null || typeof foo === "undefined") {
// foo is null or undefined
}
【讨论】：
=== 运算符的重点是代码清晰。没有合理的情况使用==，因为它永远不会像身份运算符那样清晰易懂。这与您是否了解运算符无关，而是关于使用使您的代码更易于阅读且几乎不花费任何费用的运算符。唯一反对身份运算符的开发人员是独立开发人员和不以团队形式工作的人。顾名思义，就是那些代码没有经过足够多的眼睛审查的人。
there is no reasonable situation 是一个严重的错误陈述。想想（本机）Javascript 类型 Number 和 String。它们的存在证明了 Javascript 作者对== 有一定的用例。你真的认为new String('hi') === 'hi' 评估为false 很清楚吗？请编写一个代码 sn-p 来测试您的函数参数与 'hi' 是否接受 String 和 string 并告诉我这很清楚。
JSLint 本质上比 Javascript 语法所允许的更具防御性。
来自 JSLint 文档：
==和!=运算符在比较之前进行类型强制。这很糟糕，因为它导致' \t\r\n' == 0为真。这可以掩盖类型错误。与以下任何值进行比较时，请使用
===或!==运算符（不进行类型强制）：0 '' undefined null false true如果您只关心一个值是 truthy 还是 falsy，那么请使用缩写形式。而不是
(foo != 0)只是说
(foo)而不是
(foo == 0)说
(!foo)
===和!==运算符是首选。
【讨论】：
== 运算符一起使用。 === 是一个特例...... JSLint 试图让它看起来像使用 == 会在某种程度上是错误的......但是，试试这个：var x = 4, y = new Number(4); if (x == y) {alert('Javascript depends on == just embrace it!');}。原始类型有相应的类来替代它们（Number、String），而 Javascript 依赖于 == 运算符来使这些比较自然。
请记住，JSLint 强制人们对好的 JavaScript 应该是什么样的想法。在实施它建议的更改时，您仍然必须使用常识。
一般来说，比较类型和值将使您的代码更安全（当类型转换没有按照您的想法进行时，您不会遇到意外行为）。
【讨论】：
Triple-equal 与 double-equal 不同，因为除了检查两侧是否为相同的值之外，triple-equal 还检查它们是否为相同的数据类型。
所以("4" == 4) 为真，而("4" === 4) 为假。
Triple-equal 的运行速度也稍快一些，因为 JavaScript 在给出答案之前不必浪费时间进行任何类型转换。
JSLint 旨在使您的 JavaScript 代码尽可能严格，以减少晦涩难懂的错误。它强调了这类事情，试图让你以一种迫使你尊重数据类型的方式编写代码。
但是 JSLint 的好处在于它只是一个指南。正如他们在网站上所说，即使你是一个非常优秀的 JavaScript 程序员，它也会伤害你的感情。但你不应该觉得有义务听从它的建议。如果您已经阅读了它的内容并且理解了它，但您确信您的代码不会出错，那么您就不会强迫您更改任何内容。
如果您不想被警告轰炸，您甚至可以告诉 JSLint 忽略检查类别，而您不会对此采取任何行动。
【讨论】：
引用http://javascript.crockford.com/code.html:
=== 和 !== 运算符。
使用 === 和 !== 运算符。 == 和 != 运算符会进行类型强制。在 特别是，不要使用 == 来比较 反对虚假值。
JSLint 非常严格，他们的 'webjslint.js' 甚至没有通过自己的验证。
【讨论】：
webjslint.js 没有验证——尽管我现在看到的大多数错误都与间距有关。显然，在使用 JSLint 审查 JavaScript 时，必须使用常识和合理的判断。
always这个词会自动取消这句话的智慧。聪明的程序员不是教条主义的。他们在给定的情况下使用最好的。他们欢迎并接受任何内置于语言核心的工具，而不仅仅是用just never touch it 将其驳回。底线：我的代码更短（不仅仅是节省了一个 = 字符），因此我的网站加载速度更快，带宽成本更低，因此我的用户得到了更好的服务。
如果您想测试虚假性。 JSLint 不允许
if (foo == null)
但确实允许
if (!foo)
【讨论】：
===。
foo == null 检查 null 或 undefined。 !foo 检查 null、未定义、0 和空字符串。
为了帮助解释这个问题并解释为什么 NetBeans (from) 7.3 开始显示此警告，这是从 NetBeans 错误跟踪器上的响应中摘录的，当时有人将此报告为错误：
在 JavaScript 中使用 === 而不是 == 是一种很好的做法。
== 和 != 运算符在比较之前进行强制类型转换。这很糟糕，因为 它导致 ' \t\r\n' == 0 为真。这可以掩盖类型错误。 JSLint 不能 可靠地确定 == 是否被正确使用，因此最好不要使用 == 和 != 并始终使用更可靠的 === 和 !== 运算符 而是。
【讨论】：
嗯，它不会真的引起问题，它只是给你建议。要么接受，要么离开它。也就是说，我不确定它有多聪明。在某些情况下，它可能不会将其视为问题。
【讨论】：