Number(null)返回0、Number(undefined)返回NaN，二者均不报错但语义失真：null本表“有意为空”却被转为0，undefined转NaN具传染性且无法用===判断，易致逻辑误判。
Number 构造函数在处理 null 和 undefined 时，会静默转换为特定数值，而非报错或保留原值——这容易引发逻辑误判。关键在于它不抛异常，却给出看似“合理”实则违背直觉的结果。
Number(null) 返回 0，但 null 并非“零值”
尽管 null 表示“有意的空”，语义上与数字无关，Number(null) 却返回 0：
-
Number(null) === 0→ true -
2 + null→ 2（因加法中null被转为0） - 这种转换掩盖了“缺失数据”的本意，比如接口返回
null表示字段未提供，却被当作0参与统计或渲染
Number(undefined) 返回 NaN，但不会中断执行
undefined 表示“未定义”，Number(undefined) 返回 NaN，且该值具有传染性：
-
Number(undefined)→ NaN -
undefined + 1→ NaN（不是报错，而是静默失败） -
isNaN(Number(undefined))→ true，但NaN === NaN为 false，无法用相等判断捕获
对比 == 与 === 下的隐式转换陷阱
当混合使用 Number() 和比较操作符时，类型转换路径更难追踪：
-
Number(null) == 0→ true（数值相等） -
Number(undefined) == 0→ false（NaN == 0恒假） -
null == undefined→ true，但Number(null) == Number(undefined)→ false（0 == NaN） - 这种不一致性让条件分支难以预测，尤其在表单校验、API 数据清洗等场景中易漏判
安全替代方案：显式检查优先于 Number() 转换
避免依赖 Number() 处理可能为 null 或 undefined 的值：
- 先用
typeof x === 'number' && isFinite(x)确认是有效数字 - 对可能为空的字段，显式过滤：
x == null ? null : Number(x)或x ?? NaN - 需要默认值时，用
Number(x ?? 0)明确意图，而非Number(x)任其隐式转换 - 校验场景推荐
!isNaN(parseFloat(x)) && isFinite(x)，比Number(x)更严格
