直接用===替代==可避免隐式类型转换问题：先判类型，不同直接false；类型相同才比值。==因复杂转换规则易致意外结果，如0==false为true；===则严格区分类型，如0===false为false。
直接用 === 替代 ==，就能绕开 JavaScript 隐式类型转换带来的各种意外结果。它的核心逻辑就两条：先看类型，类型不同立刻返回 false；类型相同才比值。没有中间转换步骤，行为清晰可控。
为什么 == 容易踩坑
== 会按一套复杂规则自动转换类型，很多结果违反直觉：
-
0 == false→true（false被转成0） -
"" == 0→true（空字符串被转成0） -
"0" == false→true（"0"→0→false） -
[] == ![]→true（两边都转为0）
这些不是靠常识推出来的，而是引擎内部抽象相等算法一步步 coercion 的结果，调试困难、难以预测。
=== 的工作方式很干净
它只做两件事，不绕弯：
- 比较前先检查类型是否一致
- 类型一致才继续比值，否则直接
false
例如：
-
0 === false→false（number≠boolean） -
"" === 0→false（string≠number） -
"0" === false→false（string≠boolean） -
[] === ![]→false（object≠boolean）
实际开发中怎么用才稳妥
日常编码默认全部使用 ===，只在极少数明确需要类型宽松比较的场景才考虑 ==（通常不建议）：
- 检查 API 响应码：
response.status === 200，避免"200" == 200引发误判 - 判断布尔状态：
isLoading === true或isValid === false，不写isLoading == true - 区分
null和undefined时必须用===：value === null、value === undefined - 若真要统一判断“空值”，可用
value == null（因null == undefined为true），但仅限这个目的且需理解其边界 - 启用 ESLint 的
eqeqeq规则，让工具自动拦截==的误用
关于 NaN 的一个细节
NaN === NaN 是 false，这符合 IEEE 754 标准。虽然 NaN == NaN 也是 false，但检测是否为 NaN 应该用 Number.isNaN(x) 或 Object.is(x, NaN)，而不是依赖相等运算符。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
