必须显式传入 parseInt 的第二个参数（基数），否则依赖自动推断会导致行为不一致、NaN 错误及跨环境差异；例如 [1,2,3].map(parseInt) 因索引被误作基数而返回 [1, NaN, NaN]，安全做法始终写 parseInt(str, 10) 等明确进制。
始终建议显式传入 parseInt 的第二个参数（基数），因为省略它会触发自动推断逻辑，而该逻辑在不同环境、不同字符串前缀下行为不一致，极易导致隐性 bug。
自动推断规则混乱且不可靠
当不传 radix 时，JavaScript 会按以下顺序“猜”进制：
- 字符串以
"0x"或"0X"开头 → 强制按十六进制解析（如parseInt("0xFF") === 255） - 字符串以
"0"开头 → 在旧规范中可能被当作八进制（如parseInt("010")曾返回8），虽 ES5+ 统一为十进制，但部分遗留代码或跨环境运行仍可能暴露差异 - 其他情况 → 默认十进制
问题在于：这个“猜”的过程不透明，也不可控。比如 parseInt("010") 在 Chrome 最新版本中是 10，但在某些 Node.js 旧版本或调试工具中可能仍是 8，仅靠字符串内容无法确定结果。
map 中误用引发的典型崩溃
常见错误写法：[1, 2, 3].map(parseInt) 表面看是把数字数组转成整数数组，实际执行的是：
-
parseInt(1, 0)→ 基数为 0，等价于十进制 →1 -
parseInt(2, 1)→ 基数 1 非法 →NaN -
parseInt(3, 2)→ 用二进制解析"3"，但二进制不含数字3→NaN
这是因为 map 会把索引（0, 1, 2...）作为第二个参数传给 parseInt。没指定 radix，就等于把索引当基数用 —— 而索引从 0 开始，直接触发非法值和解析失败。
非十进制字符串必须显式声明基数
想正确解析二进制、八进制、十六进制等，不写 radix 几乎必然出错：
-
parseInt("101")→ 返回101（十进制一百零一），不是二进制的5 -
parseInt("101", 2)→ 明确按二进制解析 →5 -
parseInt("FF", 16)→ 正确得255；若写成parseInt("FF")→NaN（开头不是0x，又不含数字，直接失败）
更隐蔽的是混合字符串：parseInt("12px", 10) 安全返回 12；但 parseInt("12px") 同样返回 12（因默认十进制且忽略后续非数字字符）。看似一样，实则依赖默认行为 —— 一旦字符串变成 "012px"，风险立刻浮现。
安全写法就是加第二个参数
无论什么场景，只要用 parseInt，就应明确写出基数：
- 解析普通数字字符串 → 写
parseInt(str, 10) - 解析用户输入的二进制 → 写
parseInt(str, 2) - 解析 CSS 单位或带前缀的值 → 先
.replace()清理，再固定radix
这不是多此一举，而是堵住所有自动推断带来的不确定性。现代 linter（如 ESLint）也默认警告无 radix 的调用 —— 因为它本质是未声明的隐式约定，违背可读性与可维护性原则。
