JavaScript字符串转数字：Number()、parseInt()与一元加号的区别

在 JavaScript 中将字符串转换为数字，最常用的三种方式是 Number() 构造函数、一元加号运算符（+）以及 parseInt() 函数。简而言之：Number() 与一元加号底层机制完全一致，它们均调用 ECMAScript 规范的 ToNumber 抽象操作，采用“全串严格转换”规则，遇到空字符串返回 0，遇到包含单位或非法字符（如 '42px'）则返回 NaN；两者的差别仅在于代码表现形式、可读性以及对 BigInt 类型的处理策略。而 parseInt() 属于“流式词法解析器”，它会从左向右逐字符扫描，遇到首个非数字字符立即截断并返回已收集的整数（能够提取 '42px' 中的 42），遇到空字符串返回 NaN，并支持通过第二个参数指定进制基数（radix）。本文将从底层规范、关键边界行为、执行流程以及工程选型四个维度，全面拆解三者的区别与最佳实践。

一、底层运作机制与架构差异

要彻底区分这三种方式，首先需要理解它们在 JavaScript 引擎内部所经历的不同处理流水线。表面上看似相同的转换结果，其背后的执行模型有着本质区别。

1. Number(str)：ECMAScript 规范定义的 ToNumber 抽象操作

当以普通函数形式调用 Number(str) 时，JavaScript 引擎会执行语言规范中的 ToNumber(argument) 抽象操作。它的解析规则非常严苛，要求整个字符串必须完整符合数值字面量的文法规范：

• 去除首尾空白：引擎会先自动剔除字符串前后的空格、制表符（ ）及换行符（ ）。
• 空字符串映射为 0：如果剔除空格后字符串为空（"" 或纯空格），规范明确规定返回 0。这是日常开发中极易引发数据污染的一个特性。
• 支持多种数值表示：能够原生识别十六进制（0x 或 0X）、二进制（0b 或 0B）、八进制（0o 或 0O）前缀，以及科学计数法（如 "1.5e3" 转换为 1500）和 Infinity。
• 全串零容忍检验：只要字符串中包含任何一个不符合数值语法的字符（例如 "12px"、"12,000"、"12a3"），整个转换流程立即宣告失败，返回 NaN。

2. 一元加号（+str）：基于表达式的高性能强转

一元加号是放置在操作数前面的单目运算符（如 +str）。在 ECMAScript 规范中，一元加号的求值语义同样是直接对其操作数执行 ToNumber() 抽象操作。因此，在对字符串的处理逻辑上，+str 与 Number(str) 的返回值是 100% 相同的。

然而，一元加号与 Number() 存在两个关键的分水岭：

• BigInt 兼容性风险：Number(100n) 允许将大整数安全降级为普通数字 100（可能丢失超限精度），但 +100n 在 JavaScript 规范中被严格禁止，会直接抛出运行时异常 TypeError: Cannot convert a BigInt value to a number。
• 语法歧义与代码可读性：在复杂的算术表达式中，连续的加号容易引起混淆，例如 const sum = 1 + + "2"; 或者与自增运算符 ++ 相邻时容易降低代码可维护性。

3. parseInt(string, radix)：逐字符词法扫描器

parseInt() 的工作方式与 ToNumber 截然不同，它不是一个强类型校验器，而是一个带有容错能力的字符流扫描器：

• 跳过前导空白：仅忽略字符串开头的空格，随后寻找首个有效字符（+、- 或当前进制下的合法数字）。
• 遇到非法字符即刻截断：游标从左往右扫描，只要遇到第一个不能作为当前进制数字的字符（例如单位字符 'p'，甚至是小数点 '.'），解析过程立即停止，并将前面扫描到的有效字符累加计算为整数返回。
• 始终截断小数：由于它专注于整数提取，遇到小数点 '.' 会被视作非法数字字符直接截断，因此 parseInt("19.99", 10) 得到的是 19，小数部分被彻底丢弃。若需要保留小数，必须使用 parseFloat()。
• 空串返回 NaN：由于在空字符串中找不到任何有效前导数字，parseInt("", 10) 安全返回 NaN，天然具备防御空输入的能力。

二、关键边界场景与行为深度比对

为了直观掌握三者在真实开发中的具体表现，我们针对日常开发中最容易踩坑的六类输入进行代码实测与结果比对。

三、实战选型指南与决策流程

面对不同的业务场景，如何快速而准确地选择最合适的转换手段？请参考以下决策树与实战场景分析：

场景 1：表单与 API 接口的严格数值校验

推荐方案：Number(str) 配合前置空串检查。

业务数据输入要求“全串合法”，任何附带的多余字符都应被视作非法输入。例如用户输入 "1200元"，我们不希望系统静默提取出 1200 并提交，而是应当明确提示格式错误。此时使用 Number() 具有最高的代码可读性和意图自解释性：

// 推荐的表单数值安全转换封装
function safeParseNumber(input) {
  if (typeof input !== 'string' || input.trim() === '') {
    return NaN; // 阻止空串静默转为 0
  }
  return Number(input); // 严格转换，任何非法字符返回 NaN
}

console.log(safeParseNumber("100"));    // 100
console.log(safeParseNumber("100px"));  // NaN (成功拦截)
console.log(safeParseNumber(""));       // NaN (成功拦截)

场景 2：提取样式与带单位的尺寸数值

推荐方案：parseInt(str, 10) 或 parseFloat(str)。

在 DOM 动画、Canvas 绘图或 CSS 属性计算中，从计算样式（getComputedStyle）获取到的值往往形如 "16px"、"1.5rem"、"100%"。这类字符串天然带有合法的非数字后缀，此时 Number() 和一元加号会全部失效返回 NaN，必须借助解析器：

const elemWidth = "250px";
const elemLineHeight = "1.6em";

// 提取整数像素宽度（必须显式传入基数 10）
const width = parseInt(elemWidth, 10); // 250

// 提取带小数的行高系数（保留浮点数）
const lineHeight = parseFloat(elemLineHeight); // 1.6

场景 3：多进制数值转换

推荐方案：parseInt(str, radix)。

当需要解析二进制、八进制或十六进制字符串，且字符串本身未带有标准前缀时（例如纯十六进制色值 "FF" 或二进制权限位 "1010"），Number() 与一元加号无法识别并会当作十进制或返回 NaN。此时 parseInt() 的 radix 参数是唯一优雅的解法：

const hexColor = "FF";
const binMask = "1011";

const r = parseInt(hexColor, 16); // 255
const mask = parseInt(binMask, 2); // 11

场景 4：高性能计算与密集热点循环

推荐方案：受控环境下使用一元加号 +str。

一元加号是语言原生单目运算符，无需函数调用的栈帧开销，在 V8 等现代 JIT 引擎中往往被内联为一条极简的类型推导指令。在数据源已知且高度受控的大规模数据清洗、WebGL 顶点处理或高频渲染循环中，一元加号拥有微弱的性能优势与极致紧凑的代码表达。但务必确保操作数绝不会包含 BigInt 变量。

四、避坑清单与速查矩阵

避坑清单（Gotchas）

1. 永远显式为 parseInt() 传递第二个参数基数 10：虽然 ECMAScript 5 起默认将没有前缀的字符串视为十进制，但在历史遗留代码、非标准运行环境或遇到以 "0" 开头的字符串时，省略基数极易产生难以察觉的进制错乱。养成始终编写 parseInt(val, 10) 的习惯是工程代码的基本规范。
2. 警惕一元加号的连续运算符与优先级陷阱：避免编写类似于 const val = +!isDone + +"10"; 这种极度晦涩的连续符号代码。团队开发中，清晰可维护的意图表达永远优于过度精简的字符数量。
3. 切勿使用 parseInt 处理科学计数法浮点数：当一个非常小或非常大的数字被转为科学计数法字符串时（例如 0.0000005.toString() 结果为 "5e-7"），执行 parseInt(0.0000005) 会得到 5，因为扫描器遇到字母 'e' 立即截断停机！

五、核心结论与记忆口诀

总结三者的分工与定位：

• Number(str)：全能严格型。用于常规业务与表单验证，意图清晰自解释；防范空串需前置加 trim() 检查。
• parseInt(str, radix)：容错截取型。用于提取带单位的整数或自定义进制解析，必须显式传入基数 10，遇到小数会截断丢弃。
• 一元加号 +str：极简性能型。转换语义与 Number() 相同，适用于已知安全的高频计算，切忌作用于 BigInt。