17370845950

=== 要求值和类型都一致，== 会强制类型转换；常见陷阱如 0 == false、"" == false、[] == false 均为 true；唯一可接受的 == 用法是 value == null 检查 null 或 undefined。

== 会强制类型转换，=== 不会

JavaScript 中 == 是抽象相等（又叫“宽松相等”），会在比较前尝试把两边转成同一类型；=== 是严格相等，要求值和类型都一致。这是最核心的区别，也是绝大多数意外行为的根源。

比如 null == undefined 返回 true，但 null === undefined 是 false；又如 "0" == 0 为 true，而 "0" === 0 为 false。

常见隐式转换陷阱有哪些

这些不是冷知识，而是日常踩坑高频点：

• 0 == false → true（false 被转成 0）
• "" == false → true（空字符串转成 0，再与 false 比）
• [] == false → true（空数组先 .toString() 得 ""，再走上面那条）
• [0] == false → true（[0].toString() 是 "0"，再转成数字 0）
• {} == true → false，但 {} == false 也 false（对象转原始值逻辑更复杂，容易误判）

什么时候能放心用 ==

几乎不能。唯一被广泛接受的例外是检查 null 或 undefined：

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

这是 ECMAScript 规范明确鼓励的简写。除此之外，所有其他 == 使用都建议替换成 ===，尤其在条件判断、数组过滤、对象键匹配等场景。

TypeScript 和 ESLint 怎么帮你避坑

即使你写的是 JavaScript，用 eslint-plugin-eslint-recommended 或 eslint:recommended 配置，默认就启用了 eqeqeq 规则，会警告所有 == 和 != 的使用。

TypeScript 编译器本身不检查这个，但配合 strict 模式 + ESLint，基本能杜绝这类问题。注意：类型断言（如 value as string）不会影响运行时比较逻辑，该错还是错。

真正难缠的不是记不住规则，而是某些库返回值类型模糊（比如 localStorage.getItem() 返回 string | null），这时候漏掉 === null 判断，又用 == "" 去测，结果 null == "" 是 false，但逻辑上你想捕获的是“没值”，反而绕过去了。