从 ['1','2','3'].map(parseInt) 看 JavaScript 中 map 与 parseInt 的“参数陷阱”
在 JavaScript 开发中，map 和 parseInt 是两个常用工具：map 用于数组遍历并生成新数组，parseInt 用于字符串转整数。但你是否遇到过这样的“诡异”现象？
console.log(['1', '2', '3'].map(parseInt));
// 输出：[1, NaN, NaN]
预期的 [1, 2, 3] 变成了 [1, NaN, NaN]，这背后隐藏着 JavaScript 中函数参数传递的“隐性规则”。本文将从基础概念入手，结合代码示例，彻底拆解这个问题的根源。
一、前置知识：map 与 parseInt 的“基础用法”
1. Array.prototype.map：数组的“变形器”
map 是数组的高阶方法，作用是遍历原数组，对每个元素执行回调函数，并将回调的返回值收集为新数组返回。其语法为：
const newArray = arr.map((currentValue, index, array) => {
// 对 currentValue 进行处理，返回新值
});
currentValue：当前遍历的元素值；index（可选）：当前元素的索引（从0开始）；array（可选）：原数组本身。
关键点：即使回调函数不需要这些参数，map 也会默认传递这三个参数。
2. parseInt：字符串的“进制解析器”
parseInt 用于解析字符串并返回指定进制的整数，语法为：
const num = parseInt(string, radix);
string：要解析的字符串（非字符串会被转为字符串）；radix（可选）：表示字符串的进制（2-36之间的整数）。若省略或为0，parseInt会根据字符串的前缀自动推断进制（如无特殊前缀默认十进制）。
关键点：radix 必须满足 2 ≤ radix ≤ 36，否则 parseInt 会返回 NaN（Not a Number）。
二、问题根源：map 传递的参数与 parseInt 的“不匹配”
回到示例代码 ['1', '2', '3'].map(parseInt)，表面上看是将数组中的每个字符串转为整数，但实际执行逻辑与预期大相径庭。
1. map 的“隐性参数传递”
当 map 调用 parseInt 作为回调时，map 会向 parseInt 传递三个参数：currentValue（当前元素值）、index（当前索引）、array（原数组）。但 parseInt 只关心前两个参数（string 和 radix），因此实际执行的是：
['1', '2', '3'].map((item, index) => parseInt(item, index));
这意味着，parseInt 的第二个参数（radix）被错误地替换为数组的索引。
2. 逐元素分析：为什么会得到 [1, NaN, NaN]？
我们逐个分析数组中的元素：
第一个元素：'1'（索引 0）
parseInt('1', 0)：
radix为0时，parseInt会自动推断进制。由于字符串'1'没有0x（十六进制前缀）或0（八进制前缀），默认按十进制解析。- 结果：
1（正确）。
第二个元素：'2'（索引 1）
parseInt('2', 1)：
radix为1，但radix必须满足2 ≤ radix ≤ 36，因此parseInt无法解析，返回NaN（非数字）。- 结果：
NaN（错误）。
第三个元素：'3'（索引 2）
parseInt('3', 2)：
radix为2（二进制），但二进制仅允许数字0和1，'3'不是有效的二进制数字。- 结果：
NaN（错误）。
总结：由于 map 错误地将索引作为 radix 传递给 parseInt，导致后两个元素无法正确解析，最终结果为 [1, NaN, NaN]。
三、解决方案：显式指定 radix 为十进制
问题的核心是 map 传递的索引干扰了 parseInt 的 radix 参数。要解决这个问题，只需显式指定 radix 为10（十进制），避免 map 传递的索引影响解析逻辑。
修正代码示例
// 显式指定 radix 为 10（十进制）
const result = ['1', '2', '3'].map(item => parseInt(item, 10));
console.log(result); // 输出：[1, 2, 3]
item => parseInt(item, 10)：回调函数仅接收item（当前元素值），并显式将radix设为10（十进制）。- 此时
map传递的索引参数被忽略，parseInt按十进制正确解析每个字符串。
四、扩展思考：类似场景的“参数陷阱”
map 与 parseInt 的“参数陷阱”并非孤例。在 JavaScript 中，许多高阶函数（如 filter、reduce）会默认传递多个参数，若回调函数未正确处理这些参数，可能导致意外行为。
示例：filter 与 parseInt 的误用
// 错误示例：试图过滤出偶数
['2', '4', '6'].filter(parseInt);
// 实际执行：['2', '4', '6'].filter((item, index) => parseInt(item, index))
// 解析过程：
// 索引0: parseInt('2', 0) → 2（true，保留）
// 索引1: parseInt('4', 1) → NaN（false，过滤）
// 索引2: parseInt('6', 2) → NaN（false，过滤）
// 最终结果：['2']（错误）
正确做法
显式定义回调函数，避免参数干扰：
// 正确示例：过滤出偶数
['2', '4', '6'].filter(item => parseInt(item, 10) % 2 === 0);
// 结果：['2', '4', '6']（正确）
五、总结
['1', '2', '3'].map(parseInt) 的“诡异”输出，本质是 map 方法默认传递的索引参数与 parseInt 的 radix 参数冲突导致的。理解 JavaScript 中函数参数的传递规则，是避免此类问题的关键。
核心结论：
map会向回调函数传递(currentValue, index, array)三个参数；parseInt的radix参数需要显式指定（如10），避免被map的索引干扰；- 高阶函数的参数传递是 JavaScript 的“隐性规则”，开发中需特别注意回调函数的参数处理。
下次遇到类似问题时，记得检查回调函数的参数是否被“意外”覆盖——这往往是解决问题的关键！
