必须显式传入radix，因省略时JavaScript依前缀自动推断进制，导致Number.parseInt("010")在不同环境结果不一致；显式指定如Number.parseInt("010", 10)可确保行为确定。
Number.parseInt() 的 radix 参数是控制解析精度的关键，尤其在处理带前缀、多进制或混合格式的字符串时，不显式指定 radix 容易引发隐式推断错误。严谨使用的核心在于：**始终传入明确的基数，避免依赖默认行为**。
为什么必须显式传入 radix？
省略 radix 时，JavaScript 会按以下规则自动推断：
- 字符串以
0x或0X开头 → 自动按十六进制（radix=16）解析 - 字符串以
0开头（ES5 及更早）→ 曾被当作八进制（radix=8），但该行为已被废弃且在严格模式下报错 - 其他情况 → 默认十进制（radix=10）
这意味着 Number.parseInt("010") 在不同环境结果可能不同（10 或 8），而 Number.parseInt("010", 10) 始终返回 10，Number.parseInt("010", 8) 始终返回 8。显式声明消除了歧义。
处理常见非原始数值字符串的实操策略
所谓“非原始数值”，包括含单位、空格、前缀、符号混杂的字符串，例如 "0x1F kg"、" -273.15°C "、"1010b"。Number.parseInt() 本身不校验后缀，只从开头提取数字部分，因此需配合预处理：
-
剥离无关后缀：用正则提取有效前缀部分，如
"0x1F kg".match(/^[^a-zA-Z]*/)[0]→"0x1F"，再传入Number.parseInt("0x1F", 16) -
统一前导符号处理：负号
-是合法起始字符，会被识别；但+不被 parseInt 接受为符号（Number.parseInt("+123")返回NaN），需提前替换或截断 -
二进制/八进制字符串需严格校验字符集：例如
Number.parseInt("102", 2)返回NaN（因为2不是合法二进制数字），应先过滤或验证输入是否只含0-1（对 radix=2）等
典型安全写法模板
不要直接解析原始字符串，推荐封装一层校验逻辑：
function safeParseInt(str, radix = 10) {
if (typeof str !== 'string') return NaN;
// 去首尾空格
const trimmed = str.trim();
if (!trimmed) return NaN;
// 检查是否符合目标进制的字符范围（简化版）
const validChars = '0123456789abcdefghijklmnopqrstuvwxyz'.slice(0, radix);
const firstNonSign = trimmed[0] === '-' ? 1 : 0;
const content = trimmed.slice(firstNonSign);
if (!/^[0-9a-z]+$/i.test(content) ||
[...content.toLowerCase()].some(c => !validChars.includes(c))) {
return NaN;
}
return Number.parseInt(trimmed, radix);
}
这样能防止因非法字符导致静默截断（如 Number.parseInt("12ab34", 10) 返回 12 而非报错），提升可维护性。
与 Number() 和 parseFloat() 的关键分界点
当输入含小数、科学计数法或单位时，别误用 parseInt：
-
Number.parseInt("3.1415") → 3（截断，非四舍五入） -
Number("3.1415") → 3.1415（完整浮点数） -
Number.parseInt("1e3") → 1（e被视为非数字终止符） -
Number("1e3") → 1000（正确解析科学计数法）
也就是说：**parseInt 只负责“提取开头整数部分”，不负责“理解数值语义”**。若原始字符串本质是带量纲的测量值（如 "25.5px"），应优先考虑 parseFloat()；若明确需整数且支持多进制（如解析颜色码 "#ff5733" 中的 "ff"），才用 Number.parseInt("ff", 16)。
