必须显式传入 parseint() 的第二个参数，否则因进制推断规则差异（如 "010" 在不同环境解析为 8 或 10）、map 自动传索引导致 nan、基数越界（非 2–36）等问题，结果不可预测。

永远不要省略 parseInt() 的第二个参数——这不是建议，而是必须遵守的实践。省略它会让解析行为变得不可预测，尤其在跨环境、跨版本或与数组方法配合时，极易产出 NaN 或错误数值。

基数不传，JS 就要“猜心思”

当只写 parseInt("010") 时，引擎必须根据字符串前缀推断进制：

• 以 "0x" 或 "0X" 开头 → 按十六进制（radix = 16）
• 以 "0" 开头 → 历史行为混乱：ES3 默认八进制，ES5+ 默认十进制，但旧版 Safari、IE 等仍可能走八进制
• 其他情况 → 默认十进制

这意味着同一行代码，在不同浏览器或 Node.js 版本中，可能返回 8 或 10。你无法靠肉眼判断结果，更难调试。

map 中直接传 parseInt 是经典翻车现场

写 ['1','2','3'].map(parseInt) 看似简洁，实际执行的是：

• parseInt('1', 0) → radix = 0 被当作十进制，返回 1
• parseInt('2', 1) → radix = 1 非法（必须 2–36），返回 NaN
• parseInt('3', 2) → 二进制里没有字符 "3"，返回 NaN

结果是 [1, NaN, NaN]，而不是直觉中的 [1, 2, 3]。这不是 bug，是 map 自动传入索引作第二参数 + parseInt 严格按两个参数签名工作的必然结果。

合法基数范围很窄，越界即失效

radix 必须是 2 到 36 的整数。超出就直接返回 NaN：

• parseInt("10", 1) → NaN（太小）
• parseInt("z", 37) → NaN（太大）
• parseInt("10", 8) → 8（合法八进制）
• parseInt("ff", 16) → 255（合法十六进制）

不显式传参，你就失去了对这个关键阈值的控制权，也掩盖了潜在的逻辑漏洞。

正确写法：始终显式声明进制

不管原始数据看起来多“像十进制”，都应明确写出 radix：

• 十进制：parseInt("123", 10)
• 十六进制：parseInt("0xFF", 16) 或 parseInt("FF", 16)
• 二进制：parseInt("1010", 2)
• 避免歧义：parseInt("010", 10) 明确表示“就是数字十，不是八进制的八”

这样写，代码可读、可测、可维护，别人一眼看懂你的意图，自己半年后回来也不会懵。