为什么90%的程序员都栽在==和===的区别上？你中招了吗

于JavaScript开发范畴之内，由类型转换机制诱发的代码异常向来都是程序员予以聚焦之物。身为历经多年从业的技术观察者，在下觉得此种语言特性不但展现出设计哲学的演化，而且还对开发者的工程素养构成了考验。

类型转换机制

console.log(1 == '1');     // true
console.log(0 == false);   // true
console.log(null == undefined); // true
console.log('' == 0);      // true

处于双等号运用在比较之际，JavaScript引擎会开启复合的类型转变处理过程。举例来讲啊，数字同字符串作比较的时候呢，引擎将会先把字符串转变成数值类型。这样的转换于日期对象跟数值进行比较之时特别显著，日期对象会借由valueOf方法转变换为时间戳。

有这样一种情况，当数组跟原始值进行比较的时候，转换规则会变得更加复杂，空数组借助toString方法会变成空字符串，接着空字符串又会转换为数值零，这种隐式转换虽说让代码书写得到了简化，然而却加大了调试的难度，特别是在处理多层嵌套对象的时候，这种情况会格外明显。

布尔值转换规则

布尔值于比较之前始终都会先被转换为数值，其中false会转变为0，true会转变为1。此一规则在跟字符串混合使用之际极易产生意外的结果，例如字符串“false”并不会被转换为布尔值false。当和对象开展比较之时，对象会先试着转换为原始值，然后再参与最终的比较。

开展实际开发期间，常常会遇见条件判断语句，在以if(x)形式存在之中，此x会被强制性地转变为布尔值，这般的转换是遵循特定规则的，除了0、NaN、null、undefined以及空字符串之外，别的值都会被转化为true，对于编写可靠的条件判断而言，理解这些规则是极其关键的。

对象转换逻辑

依照固定顺序，对象到原始值的转换会先试着运用Symbol.toPrimitive方法，要是没有此方法，下一步便是去调用valueOf，而最后才会作用于toString。日期对象属于一个特殊的例子，它的valueOf返回的是时间戳，然而普通对象返回的却是对象自身。这样产生的差异致使日期对象能够直接和数值进行比较。

let obj = {
  [Symbol.toPrimitive](hint) {
    if (hint === 'number') return 1;
    if (hint === 'string') return 'hello';
    return 'default';
  }
};
console.log(obj == 1);        // true
console.log(obj == 'hello');   // true

于实际事例当中，空对象被转化成字符串"[object Object]"，此字符串跟任何字符串作出比较的话，都会返回false。并且数组的转化更具特殊性，单元素数组有可能被转化成该元素自身，多元素数组则会被转化成用逗号相连的字符串。

let obj = {
  valueOf() {
    return 1;
  }
};
console.log(obj == 1); // true

全等运算符特性

要求类型以及值全然一致的三等号运算符，其这般严格性将隐式转换所带来的不确定性给避免掉了。在2023年的ECMAScript标准里头，全等比较针对NaN的处理依旧维持着特殊状况：任意NaN跟NaN进行比较都会返回false 。这样的设计让数值计算的精确性得以确保。

let obj = {
  toString() {
    return 'object';
  }
};
console.log(obj == 'object'); // true

若是关乎对象引用，全等比较所要求的乃是指向同一个内存地址，哪怕两个对象的内容全然相同，只要并非同一实例，便会返回false，这一特性于状态管理库里尤为关键，能够切实避免不必要的组件重新渲染。

console.log([] == ![]) // true

实际应用场景

!Boolean([]) → false

对于Node.js服务端开发而言，全等运算符现如今已变成代码规范所强加的要求，2022年GitHub统计数据表明，采用严格相等标准的代码库相较于采用宽松相等标准的代码库，在类型相关错误方面减少了15%，诸如React这样的前端框架，其虚拟DOM比较同样依托严格相等判断 。

有些特定场景之下，依然推荐运用双等号，像是与null或者undefined联合进行检测之时。代码if(x == null)能够同时对null以及undefined予以检测 , 然而严格相等则需要分别去检测。此种用法在JavaScript社区当中存在一定争议 , 但还是在主流代码库里面广泛存在着。

[] == false

最佳实践建议

Airbnb的代码规范明确规定，除了特定的情形之外，一律都要采用严格相等，TypeScript的静态类型检查能够在编译阶段找出大部分类型不匹配的问题，近年来兴起的Deno运行时默认开启严格模式，进一步规范了比较运算的运用。

针对新手开发者而言，提议将ESLint规则的eqeqeq选项设置成"always"。于团队协作项目里，统一的比较运算符规范能够明显地削减代码维护成本。与此同时，建议多多运用TypeScript，它的类型系统能够从根源上防止诸多类型转换问题。

于你的编程实践里头，有没有曾经因为双等号的那种隐式转换致使过那种特别难以让自己察觉出来的程序错误呀？欢迎在评论区域分享你所经历的调试状况，要是感觉这篇文章对你有帮助的话那就请点赞给予支持哟。

[] == false
→ [] == 0
→ "" == 0
→ 0 == 0
→ true