==先类型转换后比较，===要求值和类型均严格一致；如0==false为true而0===false为false，null==undefined为true但null===undefined为false，"0"==0、""==0、[]==false、[0]==false均为true；仅value==null检查null/undefined时合理；ESLint和TS默认禁用==，动态类型场景需显式转换后用===。
JavaScript中==和===的底层行为差异
==会先尝试类型转换再比较，===要求值和类型都严格一致。这不是“松散 vs 严格”的抽象说法，而是具体到每种类型组合都有明确定义的算法。
比如0 == false为true，因为false被转成0；但0 === false是false，因为一个是number，一个是boolean。
哪些值用==会意外相等
这些组合在真实项目里容易引发隐蔽 bug：
-
null == undefined→true（但null === undefined是false） -
"0" == 0→true（字符串转数字） -
"" == 0→true（空字符串转为0） -
[] == false→true（空数组先转为空字符串，再转为0） -
[0] == false→true（[0]转字符串是"0"，再转数字是0）
什么时候==反而比===更合理
极少，但存在。典型场景是检查null或undefined：
立即学习“Java免费学习笔记（深入）”；
if (value == null) {
// 等价于 value === null || value === undefined
}
这个惯用法比写两个===更简洁，且是 ECMAScript 明确推荐的写法。其他情况基本没有正当理由用==。
ESLint 和 TypeScript 怎么帮你避开陷阱
现代工具链默认禁用==：
- ESLint 规则
eqeqeq: "error"会直接报错 - TypeScript 在
strict模式下对==给出警告，尤其当两边类型明显不兼容时（如string == number） - Chrome DevTools 控制台里输入
0 == ""会加灰色提示“Use ‘===’ instead”
真正难防的是动态类型场景，比如从表单input.value拿到的永远是字符串，却和数字变量比较——这时不靠工具，得靠意识：只要涉及用户输入、URL 参数、JSON 解析结果，一律先显式转换再用===。
