防止NaN关键在于控制转换入口、明确失败边界、拒绝隐式侥幸；需先trim和正则清理字符串，再用parseFloat/parseInt（指定进制），并用typeof value === 'number' && isFinite(value)校验有效数字。
防止 JavaScript 类型转换产出 NaN，关键不是“避免转换”，而是“控制转换入口、明确失败边界、拒绝隐式侥幸”。NaN 本身不可怕，可怕的是它悄无声息地混进计算链、被布尔判断误判、最终导致逻辑错乱却难以定位。
转数字前先清理再验证
用户输入、DOM 值、API 返回的字符串常带干扰字符（空格、$、,、%、px、单位等）。直接丢给 Number() 或 parseInt() 很容易触发 NaN。
- 用
.trim()清除首尾空白和换行 - 对含格式的字符串（如
"¥1,234.50"），优先正则提取纯数字部分：str.replace(/[^0-9.-]/g, '') - 再传入
parseFloat()（需小数）或parseInt(str, 10)（整数，务必指定进制） - 绝不依赖
+"123px"或str / 1这类隐式写法——它们对空串、null、undefined行为不一致
转换后必须双重校验
isNaN() 单独用有陷阱：它会先尝试把参数转成数字，undefined、{}、"abc" 都返回 true，但 null 和 "" 却返回 false（因为 Number(null) === 0）。真正要确认“是合法数值”，应组合判断：
-
typeof value === 'number'—— 先保类型是 number -
isFinite(value)—— 再排除Infinity和-Infinity - 合起来：
typeof value === 'number' && isFinite(value)
这个组合能准确识别有效数字，且不会把 0、-0 当作错误值误杀。
立即学习“Java免费学习笔记（深入）”；
业务逻辑中慎用隐式布尔判断
if (value) { ... } 看似简洁，但在数值场景下极危险：0、-0、NaN、""、null、undefined 全部为 false。而“余额为 0 元”“页码为 0”往往是完全合法的关键状态。
- 判断“是否存在”：用
value != null（兼容null和undefined） - 判断“是否为有效数字”：用上面的
typeof ... && isFinite(...) - 判断“是否允许为零”：显式写
if (count >= 0)或if (Number.isInteger(count))
统一封装安全转换函数
重复写校验逻辑易遗漏。建议团队内提供几个小工具，让转换行为可预期、可复用：
-
toNumber(str, fallback = 0)：内部调用Number(str)+isNaN() && isFinite()，失败时返回 fallback -
toInt(str, fallback = 0)：强制十进制解析，不接受浮点，超出Number.MAX_SAFE_INTEGER时可 warn -
toPositiveInt(str, min = 1, max = 9999)：专用于页码、数量等，自动 clamp 范围并处理边界
这样既杜绝了散落各处的 parseInt(x) 或 +x，也把容错策略收口到一处，便于后续统一升级或埋点监控。
