应始终优先使用===替代==，因==会触发隐式类型转换导致不可预测结果；唯一被接受的例外是x == null（等价于x === null || x === undefined），其余场景均需显式转换后严格比较。
直接用 === 替代 ==，绝大多数情况下就能避开隐式转换的坑。核心不是“怎么处理转换”，而是“不让它发生”。
默认禁用 ==，只在极少数明确需要时才破例
ESLint 的 eqeqeq 规则能自动拦截所有 == 和 !=。团队项目中应强制开启。日常编码中，只要看到 == 就该停一下问自己：这里真需要类型松动吗？
- 判断是否为
null或undefined：用x == null是唯一被广泛接受的例外（它等价于x === null || x === undefined），但更推荐现代写法x ?? defaultValue - 其他场景几乎都不需要：比如
'1' == 1看似方便，实则掩盖了数据类型不一致的问题；后端返回字符串 ID、前端却拿它和数字比较，这种 bug 往往上线后才暴露
遇到必须比较不同类型的场景，先显式转再严格比
当输入来源不可控（如表单值、URL 参数、API 响应），不能假设类型，那就主动控制转换过程，而不是交给 == 猜。
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 字符串转数字再比：
Number(str) === 42或parseInt(str, 10) === 42（注意parseInt("42px")会得 42，而Number("42px")是NaN） - 检查是否为空字符串或空数组：
str === ""或arr.length === 0，而不是!str或!arr（因为![]是false，但[]显然不等于false） - 布尔逻辑判断不要依赖自动转换：
if (value != null && value !== "")比if (value)更精准，尤其当value可能是0、"0"或false时
理解几个经典反直觉结果，就明白为什么不能信 ==
这些不是冷知识，而是调试时高频出现的线索：
立即学习“Java免费学习笔记（深入）”；
-
[] == false→true（空数组toString()得""，再ToNumber得0；false也转成0） -
"0" == false→true（字符串"0"转数字是0，false也是0） -
null == undefined→true，但null === undefined→false（二者语义不同，混用会掩盖初始化缺失问题） -
[1] == true→true（[1].toString()是"1"，再转数字是1；true也是1）
配合工具和习惯，把防御变成肌肉记忆
单靠人盯代码容易漏，要靠机制兜底：
- 用 TypeScript：编译期就能发现
string === number这类比较，根本进不了运行时 - 输入校验前置：函数入口对关键参数做
typeof或Number.isFinite检查，别让脏数据流到深层逻辑 - 调试时多看类型：
console.log(typeof x, x)比只看值更能定位问题源头
