=== 严格相等要求值和类型均一致，不进行隐式转换；== 抽象相等会先尝试类型转换再比较，易引发意外结果，如 null == undefined 为 true 但 null === undefined 为 false，现代开发推荐优先使用 ===。
== 会自动转换类型，=== 不会
JavaScript 中 == 是抽象相等（又叫“宽松相等”），执行前会尝试把两边转成同一类型再比较；=== 是严格相等，要求值和类型都一致，不进行任何隐式转换。
比如 null == undefined 返回 true，但 null === undefined 是 false；"0" == 0 是 true，而 "0" === 0 是 false。
常见踩坑场景：
-
0 == false→true（false被转为0） -
"" == false→true（空字符串转为0，再与false比较） -
[] == ![]→true（数组转空字符串再转0，![]是false，再转0）
什么时候用 == 可能合理
极少数情况下，== 的类型松散性反而有用，比如判断某个值是否为 null 或 undefined：
value == null 等价于 value === null || value === undefined，比写两个条件更简洁。
但要注意：这仅适用
null 和 undefined** 的场景。如果只允许 undefined，或只允许 null，就必须用 ===。
其他所谓“方便”的用法（如 event.target.value == "submit"）其实掩盖了类型不确定性，容易在后续逻辑中引发意外。
ESLint 和 TypeScript 默认禁用 ==
现代工具链普遍把 == 当作潜在 bug 来拦截：
- ESLint 规则
eqeqeq默认要求使用=== - TypeScript 编译器不会报错，但配合 ESLint 后会标红
== - React / Vue 官方示例、主流开源库源码中几乎找不到
==
这不是教条主义——而是因为隐式转换规则复杂（ECMA-262 §7.2.13 定义了 12 种分支路径），人脑很难穷举所有组合。一旦依赖 ==，等于把逻辑正确*给引擎的转换表。
字符串数字混用时 === 更安全
用户输入、URL 参数、JSON 数据常以字符串形式存在，但业务逻辑可能需要数值比较：
比如表单里 input.value 是 "42"，而后端返回的 id 是数字 42。用 == 看似能“自动对齐”，但风险在于：
-
"42" == 42→true -
"42abc" == 42→false（转数字失败，得NaN，NaN == 42恒为false） -
" 42 " == 42→true（字符串先被 trim？不，是直接调用ToNumber，会忽略首尾空格）
这些行为不直观。更可控的做法是显式转换：Number(input.value) === 42 或 parseInt(input.value, 10) === 42，出错时也能快速定位是转换失败还是值不匹配。
类型模糊的地方，强制显式处理，比依赖 == 的黑箱转换更利于长期维护。
