核心是让隐式转换可预测、可控制、可审查；===禁用类型转换，number()/string()/boolean()显式转换，校验有效性，区分存在性与真值判断。
避免隐式转换的逻辑漏洞，核心不是“消灭转换”，而是让类型行为可预测、可控制、可审查。JavaScript 的隐式转换本身有明确规范（ECMAScript 第9章），问题出在开发者没意识到它正在发生，或误判了转换路径。
用 === 替代 ==，堵住最危险的入口
双等号是隐式转换最高发、最隐蔽的场景。它会触发抽象相等算法（Abstract Equality Comparison），内部调用 ToNumber、ToString、ToBoolean 等规则，路径复杂且反直觉：
- [1] == "1" → true（数组先 toString 得 "1"，再与字符串比较）
- [] == false → true（[] → "" → 0，false → 0）
- null == undefined → true（唯一特例，但 === 下为 false）
一律使用 ===，类型不同直接返回 false，不走任何转换逻辑。团队代码规范中应明令禁止 == 和 != 出现在生产代码里。
数值运算前显式转数字，不依赖 +、- 等运算符的副作用
像 "42" - 0 或 +"1.5" 看似简洁，实则隐藏了 ToNumber 规则：空格被忽略、非法字符导致 NaN、"" → 0、null → 0、undefined → NaN。
推荐写法：
- 通用数字转换：
Number(str)（语义清晰，失败得 NaN） - 整数提取（仅限字符串开头）：
parseInt(str, 10)（必须指定进制，避免 "08" 被当八进制） - 浮点数：
parseFloat(str)（比Number()更宽容，如 "12.34px" → 12.34）
关键动作：转换后立刻校验有效性 —— !isNaN(num) && isFinite(num)。
字符串拼接不靠 +，改用模板字面量或 String()
value + "" 是典型隐式陷阱：若 value 是对象，会调用 toString() → "[object Object]"；若 value 是数组，得 "1,2,3"；若 value 是 null，得 "null" —— 这些都不是你真正想表达的语义。
更安全的做法：
- 意图明确的字符串化：
String(value)（对 null/undefined 返回 "null"/"undefined"，符合直觉） - 带上下文的拼接：
\`${value}\`（模板字面量内部也调用 String()，但语法即契约） - 避免
obj + ""或arr + "suffix"这类模糊写法
真假判断时，区分“是否存在”和“是否为真值”
JS 的 falsy 值只有 7 个：false、0、-0、0n、""、null、undefined、NaN。但 "0"、"false"、[]、{} 全是 truthy —— 这极易引发逻辑错判。
例如用户输入 "0"，if (input) 为 true，但业务上可能需特殊处理：
- 只检查是否为空或未定义：
input != null（涵盖 null/undefined） - 严格排除空字符串：
input !== "" && input != null - 需要布尔语义时，显式转：
Boolean(input)或!!input（但注意!!"0"是 true）
别让 if 语句成为类型转换的黑箱。
不复杂但容易忽略：隐式转换本身没错，错的是“不知道它正在发生”。每次写 ==、+、if、&& 之前，花半秒问自己——我清楚左右操作数的类型吗？它们在这里会被怎么转？答案不确定，就换成显式写法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
