核心是转前看清数据、转后确认语义；需清洗字符串（trim、正则提取）、用number而非parseint、双重校验isnan&&isfinite；区分“是否存在”与“是否为零”；运算前明确转换；封装tonumber/toint/topositiveint等安全函数。
避免类型转换过程中的数值逻辑错误，核心不是“怎么转”，而是“转之前看清数据、转之后确认语义”。很多看似是类型问题的 bug，其实是数值含义被悄悄篡改了——比如把带单位的字符串当纯数字算，把空格包裹的" 123 "当成有效输入，或者把"0"当作假值跳过关键分支。
字符串转数值：先清洗，再校验，不信任“看起来像”
用户输入、API返回、Excel导出的数据，表面是数字，实际常混杂空格、符号、千分位、单位甚至乱码。直接 Number() 或 parseInt() 容易失真：
- 用 trim() 清除首尾空白和换行，再传入转换函数
- 对含货币、百分比等格式的字符串，先用正则提取纯数字部分，例如：
str.replace(/[^0-9.-]/g, '') - 用 Number(str) 而非 parseInt —— 后者会截断小数、忽略后缀；前者对非法输入统一返回 NaN，行为更可控
- 必须搭配 isNaN() && isFinite() 双重检查，不能只看是否为数字字面量
数值参与逻辑判断：区分“是否存在”和“是否为零”
if (value) { } 在数值场景下极危险：0、-0、NaN 都会被判为 false，但业务中“余额为 0 元”“页码为 0”往往是合法且关键的状态。
- 判断“有值且非空”：用 value != null && value !== undefined，避开 0 和 "" 的误判
- 判断“是有效数字”：用 typeof value === 'number' && isFinite(value)
- 业务上允许 0：显式写 if (count >= 0) 或 if (Number.isInteger(count))，不依赖隐式布尔转换
运算前统一类型，不依赖操作符自动提升
HTML 表单值默认是字符串，+ 可能拼接，/ 虽会转数字但遇到空值或非数字就产出 NaN，且不易追踪。
- 所有数值计算前，用 parseFloat()（带小数）或 parseInt(val, 10)（整数）明确转换
- 加容错判断：
if (isNaN(a) || isNaN(b)) throw new Error('数值输入无效') - 禁止用
+val或val / 1等“快捷写法”——可读性差，且对 null、undefined、空字符串行为不一致
封装安全转换函数，让团队行为一致
重复写校验逻辑容易遗漏。建议统一提供几个小工具：
- toNumber(str, fallback = 0)：内部调用 Number + isNaN + isFinite，失败时返回 fallback
- toInt(str, fallback = 0)：强制按十进制解析，不接受浮点，超出安全整数范围时告警
- toPositiveInt(str, min = 1, max = 9999)：专用于页码、数量等有业务边界的场景，自动 clamp 范围
这些函数把清洗、校验、兜底全包进去，调用方只需关注“我要什么值”，不用每次操心“它到底是不是真的数字”。
