js中==会隐式转换类型后比较值，===则严格比较类型和值；如"1"==true为true，但"1"===true为false；推荐默认使用===，仅null==undefined等极少数场景例外。
JS 中双等号（==）会做隐式类型转换后再比较值，三等号（===）不转换类型，直接要求类型和值都完全一致。绝大多数场景下，===更安全、逻辑更可预测。
双等号（==）的隐式转换规则
当两边类型不同时，==按固定顺序尝试转换，常见规则如下：
-
数字与字符串：字符串转为数字再比，如
"123" == 123→123 == 123→true -
布尔值参与比较：
true转为1，false转为0，如false == 0、true == "1"都为true -
null 和 undefined：二者互相相等，
null == undefined是唯一特例，但null == 0或null == ""都是false -
对象与原始值：对象先调用
valueOf()（失败则用toString()）转成原始值，再继续转换比较，如[] == false→"" == false→0 == 0→true -
NaN 的特殊性：任何值（包括自身）用
==与NaN比较都为false
三等号（===）不进行任何隐式转换
===跳过所有类型转换步骤，只做两件事：
- 先判断左右操作数的 类型是否相同；类型不同直接返回
false - 类型相同时，再判断 值是否严格相等（注意：
NaN === NaN仍为false）
例如："5" === 5 → 类型不同（string vs number）→ false；0 === false → 类型不同（number vs boolean）→ false；null === undefined → 类型不同（object vs undefined）→ false。
什么时候可能需要双等号？
实际开发中几乎不需要依赖 == 的转换逻辑。极少数可接受的例外是：
- 明确需要宽松匹配
null或undefined，比如if (val == null)等价于val === null || val === undefined - 处理 DOM 属性或表单输入时，某些 API 返回值类型不稳定（如
input.value总是字符串，但期望数值逻辑），但此时更推荐显式转换（Number(x) === y）而非依赖==
为什么推荐默认用三等号？
隐式转换规则复杂且反直觉，容易引发隐蔽 bug：
-
[] == ![]结果是true（空数组转""→0；![]是false→0） -
{}和0、false、""比较结果各不相同，难以记忆 - 团队协作中，
==行为依赖开发者对整套转换规则的掌握，而===含义清晰、行为稳定
现代 ESLint 规则（如 eqeqeq）也默认禁止 ==，除非加注释说明理由。
