用===替代==不是解决而是避免类型转换bug；===先判类型，不同直接返回false，无隐式转换；仅value==null可简写null/undefined检查，但推荐value===null||value===undefined或??操作符。
用 === 替代 == 并不能“解决”类型转换 bug，而是直接避免它发生。90% 的相关问题源于开发者误以为 == 会做“合理”的隐式转换，而 JavaScript 的抽象相等算法（Abstract Equality Comparison）其实非常反直觉。
为什么 == 是 bug 温床
== 在比较前会按固定规则强制类型转换，比如：
-
0 == false→true（false转成0） -
"" == false→true（空字符串转成0，再与false比） -
"0" == false→true（"0"→0→false） -
[] == ![]→true（空数组转为""，取反后是false，再比…结果为true）
这些不是设计缺陷，而是语言规范；但它们和日常逻辑冲突，极易在条件判断、表单校验、状态匹配中埋下隐患。
=== 不是“更严格”，而是“不转换”
=== 只做一件事：先判类型，类型不同直接返回 false，不尝试任何转换。
-
0 === false→false（number≠boolean） -
"0" === 0→false（string≠number） -
[] === []→false（两个不同对象引用）
这意味着：你写的比较逻辑，就是它实际执行的逻辑——没有隐藏步骤，没有意外路径。
什么时候真需要 ==？基本不需要
极少数场景看似需要宽松比较，比如检测 null 或 undefined：
-
value == null等价于value === null || value === undefined
但现代写法更推荐显式表达：value == null 可读性差，且一旦 value 是 0、false、"" 就出错。应改用：
-
value === null || value === undefined（清晰） -
value == null（不推荐，语义模糊） -
value ?? "default"（ES2020 空值合并，更安全）
落地建议：三步建立防御习惯
-
全局开启 ESLint 规则：
eqeqeq: ["error", "always"]，让编辑器/CI 直接报错== -
审查旧代码时，把所有
==当作潜在 bug：逐个确认是否真需类型转换；99% 情况下应改为=== -
涉及用户输入或 API 返回值时，先断言类型再比较：例如
typeof data.id === "string" && data.id === "123"
