强制类型转换需结合校验与语义策略才能规避逻辑错误：转Number优先用Number()+isNaN()校验；转String用String()兜底null/undefined；转Boolean按业务显式定义；统一封装toSafe*函数提升可靠性。
强制类型转换本身不规避错误，反而容易引发逻辑错误——关键在于“怎么用”。盲目加 (int) 或 Number() 很可能把脏数据悄悄变成 0、NaN 或 false，让判断失效、查询错位、计算失真。真正能规避逻辑错误的，是结合校验、边界控制和语义明确的转换策略。
转 Number：别信 parseInt，优先用 Number() + 显式校验
很多人习惯用 parseInt("123abc") 得到 123，却忽略它对 "abc123" 返回 NaN、对 "123.45" 截断为 123。这种“取前段整数”的行为在 ID、页码、金额等场景极易埋雷。
- 用
Number(str)判断是否为有效纯数字：它对"123"→ 123，"123abc"→ NaN，""→ 0，" 123 "→ 123（自动 trim） - 必须配合
isNaN()或严格全等判断：const n = Number(input); if (isNaN(n) || !isFinite(n)) throw "非法数值" - 对分页、偏移量等有业务含义的数字，额外加范围检查：
if (n 10000) n = 1;
转 String：慎用 toString()，null/undefined 要兜底
value.toString() 简洁高效，但遇到 null 或 undefined 直接报错，线上崩溃往往就来自这一行。而 String(value) 或 value + "" 能安全返回 "null" 或 "undefined"，适合日志、拼接、展示类场景。
- 需要保留原始语义（比如后端返回 null 表示“无值”）：用
String(value)，它把 null → "null"，undefined → "undefined" - 需要空值显示为空字符串：用
value == null ? "" : String(value) - 避免
obj.prop.toString()前不判空，应写成(obj.prop ?? "").toString()或String(obj.prop)
转 Boolean：别依赖隐式转换，按语义显式定义
if (value) { ... } 看似简单，但 0、""、null、undefined、NaN 全部为 false——这常导致“0 是有效值却被跳过”，比如用户余额为 0 元，翻页参数 page=0 被当成 false 而走默认逻辑。
- 判断“是否存在”：用
value != null && value !== undefined，比if (value)更精准 - 判断“是否为真值（如开关状态）”：明确用
Boolean(value)，它只对 false、0、""、null、undefined、NaN 返回 false - 业务上“0 是有效值”：不要用
if (count)，改用if (count >= 0)或if (Number.isInteger(count))
统一入口：封装可复用的类型安全函数
重复写 Number(x), isNaN(), isFinite() 容易遗漏。建议封装几个小工具，让团队约定一致：
-
toInt(str, fallback = 0)：只接受整数字符串，否则返回 fallback -
toSafeString(val)：返回非 null/undefined 的字符串，否则空串 -
toBool(val, truthy = ["true", "1", 1])：按业务定义哪些值算 true，避免魔数
这些函数把“转换+校验+兜底”打包在一起，既防错又提升可读性，比零散调用更可靠。
