必须显式传入 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)明确表示“就是数字十，不是八进制的八”
这样写，代码可读、可测、可维护，别人一眼看懂你的意图，自己半年后回来也不会懵。
