javascript number 类型隐式转换风险高：tofixed()等返回字符串，+和比较运算符易触发意外转换，应显式转换、用===替代==、用isfinite校验数值有效性。
JavaScript 中 Number 类型在表达式里看似“安全”，实则常因隐式转换悄悄改变行为——比如 toFixed() 返回字符串、+ 运算符把数字变成拼接、== 把 0 和 false 判为相等。规避关键不是避开 Number，而是切断它被自动拖进非预期上下文的路径。
警惕 Number 方法的返回类型陷阱
Number.prototype.toFixed()、toPrecision()、toLocaleString() 全部返回字符串，不是 Number。一旦后续参与关系运算（如 >、）或数学运算，就会触发字符串到数字的隐式转换，而这个过程可能出人意料：
-
"2.00" > "11.00"→true（按字典序比较，不是数值大小） -
+"2.00" + 1→3（一元加号触发 ToNumber，但写法易被忽略） - 正确做法：需要数值结果时，立刻用
Number(num.toFixed(2))或parseFloat(num.toFixed(2))显式兜底
加法和关系运算符是隐式转换高发区
+ 和 >/ 看似只处理数字，实则对操作数类型极为敏感：
-
1 + []→"1"（空数组转为空字符串，再拼接） -
1 + {}→"1[object Object]"（对象调toString()） -
5 > "42"→false（字符串"42"被转成 42，5 - 保险做法：数值计算前统一用
Number(x)或+x；字符串拼接明确用模板字面量${x}
比较操作必须用严格相等
== 会尝试把两边都转成同一类型再比，Number 在其中常被“牺牲”：
-
0 == false→true（false → 0） -
"0" == false→true（"0" → 0，false → 0） -
"" == 0→true（"" → 0） - 一律改用
===；若需兼容 null/undefined，默认值用空值合并??，而非||
数值有效性判断不能只靠真假值
if (num) 对 0、NaN、Infinity 都会误判，尤其 0 是合法数值：
-
Boolean(0)→false，但 0 是有效计数 -
!isNaN(num) && isFinite(num)才能确认是普通数字 - 用户输入后建议：先
const n = Number(input.trim())，再校验isFinite(n)，而非依赖n || 0
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
