=== 要求值和类型都一致，== 会强制类型转换；常见陷阱如 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：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
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，但逻辑上你想捕获的是“没值”，反而绕过去了。
