17370845950

==先类型转换后比较，===要求值和类型均严格一致；如0==false为true而0===false为false，null==undefined为true但null===undefined为false，"0"==0、""==0、[]==false、[0]==false均为true；仅value==null检查null/undefined时合理；ESLint和TS默认禁用==，动态类型场景需显式转换后用===。

JavaScript中==和===的底层行为差异

==会先尝试类型转换再比较，===要求值和类型都严格一致。这不是“松散 vs 严格”的抽象说法，而是具体到每种类型组合都有明确定义的算法。

比如0 == false为true，因为false被转成0；但0 === false是false，因为一个是number，一个是boolean。

哪些值用==会意外相等

这些组合在真实项目里容易引发隐蔽 bug：

• null == undefined → true（但null === undefined是false）
• "0" == 0 → true（字符串转数字）
• "" == 0 → true（空字符串转为0）
• [] == false → true（空数组先转为空字符串，再转为0）
• [0] == false → true（[0]转字符串是"0"，再转数字是0）

什么时候==反而比===更合理

极少，但存在。典型场景是检查null或undefined：

if (value == null) {
  // 等价于 value === null || value === undefined
}

这个惯用法比写两个===更简洁，且是 ECMAScript 明确推荐的写法。其他情况基本没有正当理由用==。

ESLint 和 TypeScript 怎么帮你避开陷阱

现代工具链默认禁用==：

• ESLint 规则 eqeqeq: "error" 会直接报错
• TypeScript 在strict模式下对==给出警告，尤其当两边类型明显不兼容时（如string == number）
• Chrome DevTools 控制台里输入0 == ""会加灰色提示“Use ‘===’ instead”

真正难防的是动态类型场景，比如从表单input.value拿到的永远是字符串，却和数字变量比较——这时不靠工具，得靠意识：只要涉及用户输入、URL 参数、JSON 解析结果，一律先显式转换再用===。