核心思路是让类型转换过程可见：用console.log(typeof val, val)查真实类型，eslint启用eqeqeq和no-implicit-coercion规则拦截==，将模糊比较拆为明确判断，调试时用debugger+手动模拟抽象相等算法。
遇到因误用 == 引发的逻辑异常，比如条件判断意外为真、表单校验失效、金额计算错乱，核心思路不是“猜哪里错了”，而是“让转换过程可见”。下面几招直击要害，不绕弯。
看控制台输出的原始类型和值
别只写 console.log(val)，要同时检查类型和值：
- 用
console.log(typeof val, val)确认变量真实类型（注意：typeof null是"object"，这是历史 bug） - 对可疑比较写完整表达式，例如：
console.log('a == b:', a, typeof a, b, typeof b, a == b, a === b) - 特别关注
null、undefined、空字符串''、数字0、布尔false、空数组[]这些容易互相“伪装”的值
用 ESLint 主动拦截高危写法
靠人眼扫代码效率低还易漏。配置 ESLint 规则能实时标出问题：
- 启用
eqeqeq规则（推荐"always"模式），它会警告所有==和!=的使用 - 搭配
no-implicit-coercion，防止+x、!!x、x + ''等隐式转换写法 - 在 CI 流程中强制检查，避免带
==的代码合入主干
把模糊比较拆成明确判断
很多 == 场景其实本意是“是否为空”或“是否为有效值”，直接换成语义清晰的写法：
- 想判断
null或undefined？用val == null虽然能工作，但更推荐val === null || val === undefined，或现代写法val ?? 'default' - 想判断“假值但非 0”？别写
if (!val)，改用if (val === '' || val === false || val === null || val === undefined)，或按业务需求精确定义 - 表单输入值比较？先统一转类型：
Number(inputValue) === expectedNumber，而不是inputValue == expectedNumber
复现时加断点观察抽象相等算法路径
当某个 == 行为完全反直觉（比如 [] == ![] 返回 true），打开浏览器 DevTools，在该行打 debugger，然后手动模拟规范步骤：
- 查两边类型 → 若不同，看属于哪类分支（数字 vs 字符串？对象 vs 原始值？）
- 调用对应抽象操作：如字符串转数字用
Number()，对象转原始值看valueOf()或toString() - 把中间结果一步步打印出来，例如：
console.log(Number([]), Number(![]))就能发现两者都是0
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
