== 会触发隐式类型转换，=== 严格比较值和类型不转换；null == undefined 为 true 但 === 为 false，0/""/"0" == false 均为 true，数组对象比较依赖 toString()/valueOf()。
JavaScript 的 == 和 === 到底差在哪？
根本区别在于 == 会触发隐式类型转换，而 === 严格比较值和类型，不转换。很多诡异 bug 都源于写成了 == 却以为在做“相等判断”。
-
null == undefined返回true，但null === undefined是false -
0 == false、"" == false、"0" == false全为true—— 这不是直觉，是规范定义的抽象相等算法（ToNumber + ToBoolean 混合转换） - 数组或对象参与
==比较时，会先调用toString()或valueOf()，结果不可控：例如[0] == false是true
哪些操作符/场景会悄悄触发隐式转换？
除了 ==，还有不少“安静”的转换点，容易被忽略：
-
if (x)、while(x)等布尔上下文：会调用ToBoolean，0、NaN、""、null、undefined、false全部转为false -
+运算符：若任一操作数是字符串，另一方会被转成字符串拼接；否则全转为数字相加：1 + "2"→"12"，但1 + [2]→"12"（因为[2].toString()是"2"） -
!x：先转布尔再取反，!"0"是false（因为非空字符串转布尔为true），但!0是true -
Number(x)、String(x)、Boolean(x)显式转换虽可控，但若传入复杂对象（如new Date()、{}），结果仍依赖其valueOf()/toString()实现
怎么写才能避开隐式转换陷阱？
核心策略是：显式、确定、可预测。不要依赖 JS 帮你猜意图。
- 一律使用
===和!==，禁用==/!=（ESLint 规则eqeqeq可强制） - 判断“是否为真值”时，明确写出意图：
if (x != null)比if (x)更安全；需要检查是否为0就直接x === 0 - 字符串拼接前确保类型：
String(a) + String(b)或模板字面量${a}${b}（后者也会隐式调用ToString，但比+更可读） - 解析数字时不用
+或Number()处理不确定输入：优先用parseInt(str, 10)（需校验返回NaN）或parseFloat()；更健壮用Number.isFinite(Number(str))
一个典型错误案例和修复
常见误判用户输入是否为空：
立即学习“Java免费学习笔记（深入）”；
function isEmpty(value) {
return !value; // ❌ 错误：0、"0"、[]、{ } 都会返回 true
}
// ✅ 正确做法：按业务明确定义“空”
function isEmpty(value) {
if (value == null) return true; // null/undefined
if (typeof value === 'string') return value.trim() === '';
if (Array.isArray(value)) return value.length === 0;
if (typeof value === 'object') return Object.keys(value).length === 0;
return false;
}
隐式转换的灵活性本质是历史包袱，不是设计优势。真正可靠的代码，从不把类型交由运行时“自动协商”。越早显式声明意图，越少半夜被 {} == ![] 这种表达式惊醒。
