类型转换错误是js线上bug高频源头，因隐式转换（如==、if）不报错却导致nan/false/意外值；应全局替换==为===，数字运算前用number()校验，启用eslint eqeqeq等规则拦截。
类型转换错误是 JS 线上 Bug 的高频源头——它不抛错、不中断执行，只悄悄把结果变成 NaN、false、空字符串或意外数字，等你上线后用户反馈“计数不对”“按钮点不动”才开始抓耳挠腮。
盯紧 == 和 if 里的隐式转换
松散相等（==）和流控语句（if、while）是类型转换最活跃的两个场景。它们会自动调用 ToBoolean 或 ToNumber，而规则反直觉：
-
0 == false→ true（但0 === false是 false） -
"" == false→ true，[] == false→ true -
if ("0")→ 执行（非空字符串转布尔为 true），但if (parseInt("0"))→ 不执行（0转布尔为 false）
排查时直接全局搜索 ==、!=，替换成 === / !==；对所有 if (x) 类判断，加一行 console.log('x:', x, 'typeof:', typeof x) 看真实值和类型。
算术运算前务必校验数字有效性
+、-、*、/ 遇到非数字会静默转成 NaN，且 NaN 参与任何计算仍得 NaN，一路污染下去。
- 典型陷阱：
let count = input.value + 1→ 若input.value是空字符串或"abc"，结果就是"abc1"或NaN - 安全写法：先用
Number()或parseFloat()显式转，再用isNaN()检查 - 示例：
const n = Number(input.value); if (isNaN(n)) throw new Error('输入不是有效数字');
警惕 parseInt 和 parseFloat 的默认行为
parseInt("08") 在旧版引擎中返回 0（被当八进制），parseInt("2.5px") 返回 2（忽略后续非数字），parseFloat("abc") 返回 NaN —— 这些都容易漏检。
- 固定方案：始终传入进制参数，
parseInt(str, 10) - 更健壮替代：
Number(str)（对格式更严格，Number("2.5px")直接得NaN） - 线上排查：在涉及数字解析的函数入口加日志，打印原始字符串和转换后结果
用严格模式和工具提前拦截
很多类型转换错误本可早暴露：'use strict' 不会阻止 ==，但它能捕获未声明变量（避免 undefined + 1 这类源头问题）；ESLint 规则如 eqeqeq（强制全等）、no-implicit-coercion（禁止隐式转换）能从编码阶段卡住大部分风险。
- 立即行动：在所有新文件顶部加
'use strict'; - 配置 ESLint：启用
eqeqeq、no-undef、no-unused-vars - 测试覆盖关键路径：对用户输入、API 返回字段做类型断言，比如
expect(typeof res.id).toBe('number')
