我在 JavaScript 里把一个字符串数组用 map 直接交给 parseInt 想批量转成数字、写法简洁我很满意,结果转出来是 1、NaN、NaN 一片狼藉,我盯着这行干净利落的代码百思不得其解,最后才搞懂 map 会偷偷给回调塞三个参数、而 parseInt 把其中那个下标当成了进制

这是一次让我把 JavaScript 里"把函数直接当回调传给 map"这件事,从"简洁优雅",重新理解成"map 会偷偷塞多个参数、那个函数可能把它们用错"的事故。我把一个字符串数组用 map 直接交给 parseInt 想批量转成数字,写法简洁我很满意。结果转出来是 1, NaN, NaN 一片狼藉。我盯着这行干净利落的代码百思不得其解,最后才搞懂:map 会偷偷给回调塞三个参数,而 parseInt 把其中那个下标当成了进制。这篇就把这次"map(parseInt) 转出一堆 NaN"的事故,从头到尾复盘一遍。

故障现场:["1","2","3"].map(parseInt) 竟是 [1, NaN, NaN]

我有一个字符串数组 ["1", "2", "3"],想把它们批量转成数字。我觉得最优雅的写法就是 arr.map(parseInt)——把 parseInt 这个"字符串转数字"的函数直接当回调传给 map,简洁、point-free、一气呵成。我满以为会得到 [1, 2, 3]。

结果一打印,傻眼了:[1, NaN, NaN]。第一个还对,后面两个全是 NaN。我反复确认数组里就是 "1"、"2"、"3" 三个正常的数字字符串,parseInt("2") 单独调明明是 2 啊。我一度怀疑是不是数组里混了奇怪的字符,检查了没有。直到我去查 map 到底给回调传了什么参数,才彻底明白根因——Array.prototype.map 在调用回调时,会传三个参数:(element, index, array)——当前元素、当前下标、原数组。而 parseInt 的签名是 parseInt(string, radix)——第一个参数是要解析的字符串,第二个参数是进制(radix,基数)。当我把 parseInt 直接当回调时,map 就把它的前两个参数喂了进去:parseInt(element, index)——也就是把数组下标当成了进制!于是实际执行的是:parseInt("1", 0)、parseInt("2", 1)、parseInt("3", 2)。parseInt("1", 0) 里 radix 为 0 被当作默认的十进制,结果是 1(碰巧对);parseInt("2", 1) 里 radix 为 1 是无效进制(进制最小是 2),返回 NaN;parseInt("3", 2) 是"把 '3' 按二进制解析",而二进制只有 0 和 1、'3' 不是合法的二进制数字,返回 NaN。我以为 map 只会把"当前元素"传给回调,可它实际上还顺手把"下标"和"整个数组"也传了进去;而 parseInt 恰好有第二个"进制"参数,就把那个本不该它接的下标,当成了进制,酿成这一片 NaN。我那行"简洁优雅"的代码,败在了一个我看不见的"多传的参数"上。

// 我的写法: 把 parseInt 直接当 map 的回调, 自以为简洁优雅
["1", "2", "3"].map(parseInt);     // 期望 [1, 2, 3]
// 实际: [1, NaN, NaN]  ✗

// 真相: map 给回调传【三个参数】(element, index, array)
//   parseInt 的签名是 parseInt(string, radix), 第二参数是【进制】
//   于是 map 把 index 当成了 radix:
parseInt("1", 0);   // radix 0 当默认十进制 → 1  (碰巧对)
parseInt("2", 1);   // radix 1 是无效进制 → NaN
parseInt("3", 2);   // "3" 按二进制解析, 二进制没有 3 → NaN

// 我以为 map 只把"当前元素"传给回调,
// 其实它还顺手传了 index 和 array, 而 parseInt 把 index 误当进制了

问题被钉死在这个认知错位上:我以为"把 parseInt 当回调传给 map"等价于"对每个元素调用 parseInt(元素)",但 map 调用回调时传的是三个参数 (element, index, array),而不是一个;当回调函数恰好能接收多个参数时(parseInt(string, radix) 能接两个),那些我"没打算传、也没意识到被传了"的额外参数(这里是 index)就会被它接走、并改变它的行为。parseInt 把 index 当成了 radix,于是从"十进制解析"变成了"按下标当进制解析",自然一片 NaN。我把一个"多参数函数"point-free 地直接当回调,而没核对它的参数签名和 map 实际传入的参数对不对得上——这种"看着干净"的写法,恰恰把"多传的参数"这个隐患藏在了简洁的外表下。我以为我只是让它"逐个处理元素",却没想到 map 每次都顺手多塞了两个参数进去,而其中一个正好被那个函数当成了改变行为的开关。

第一件事:想明白 map 传三个参数,point-free 传函数要核对签名

把这次事故彻底想清楚,关键是理解Array 的高阶方法(map、forEach、filter、some 等)在调用你传入的回调时,都会传多个参数:对 map 是 (element, index, array)。当你"point-free"地把一个现成的函数直接当回调传进去(arr.map(fn) 而非 arr.map(x => fn(x))),这个函数会接收到全部这些参数,而不只是你心里想的那个"当前元素"。如果这个函数只接收一个参数、或多出来的参数它会忽略,那没问题;但如果它恰好能接收并使用第二个、第三个参数(像 parseInt 的 radix),那么 map 多传的参数就会被它接走、悄悄改变它的行为。

这就引出了"point-free 传函数"的注意点:把一个现成函数直接当回调,只有在"它的参数签名和高阶函数实际传入的参数,在你需要的范围内对得上"时才安全。最稳妥、也最不容易出错的做法,是用箭头函数显式地只传你要的参数:arr.map(x => fn(x))——这样无论 map 传多少个参数,都只有 x 这一个被传给 fn,多余的 index/array 被箭头函数"挡"在了外面,绝不会被误用。对 parseInt 这个具体的坑,正确写法是 arr.map(x => parseInt(x, 10))(显式只传字符串、并明确指定十进制),或者直接用 arr.map(Number)(Number 只接一个参数、多传的它不理会,所以 point-free 也安全)。关键认知是:当你把一个"能接收多个参数"的现成函数,直接交给一个"会传入多个参数"的高阶机制(map、事件回调、Promise then 等)时,要警惕那些"你没打算传、却被自动传进去"的额外参数——它们可能被那个函数接走并改变行为;要么确认参数签名严格匹配,要么用一层薄薄的包装(箭头函数)显式地只传你真正想传的那些参数,把多余的挡在外面。

// 正解1: 用箭头函数显式只传你要的参数(最稳妥, 通用)
["1", "2", "3"].map(x => parseInt(x, 10));   // [1, 2, 3] ✓ 明确十进制
// 箭头函数只把 x 传给 parseInt, map 多传的 index/array 被挡在外面

// 正解2: 用只接一个参数的函数, point-free 也安全
["1", "2", "3"].map(Number);                 // [1, 2, 3] ✓ Number 只接一个参数

// 反面: 直接传"多参数函数", 会把 index 也喂进去
["1", "2", "3"].map(parseInt);               // [1, NaN, NaN] ✗

// 同类要警惕的: 任何"多参数现成函数"直接当 map/forEach 回调
[1.5, 2.5].map(Math.round);                  // [2, 3] (Math.round 只接一个, 凑巧没事)
["1","2"].forEach(console.log);              // 会打印 元素 下标 数组(三个参数都打)
//   想只打元素: .forEach(x => console.log(x))

// 通用原则: point-free 传函数前, 核对它的参数签名 vs map 传入的 (el, idx, arr)
//   不确定就用箭头函数包一层, 只传你要的

想通这一层,我才明白自己错在哪:我以为 arr.map(parseInt) 就是"对每个元素调 parseInt(元素)",却忽略了 map 给回调传的是 (element, index, array) 三个参数;而 parseInt 恰好有第二个"进制"参数,把 index 接走当成了进制,行为全变了。我贪图 point-free 的简洁,把一个"能接多参数"的函数直接当了回调,却没核对它的参数签名和 map 实际传入的参数对不对得上。根治之道,是用箭头函数显式只传我要的参数(x => parseInt(x, 10)),把 map 多传的挡在外面。不是图简洁就把现成函数直接丢给高阶方法,而是先看清它会被喂几个参数、会不会被多余的参数带偏。

第二件事:正解——箭头函数显式只传要的参数,或用单参数函数

找到根因,正解就清晰了:把现成函数当 map/forEach 等高阶方法的回调时,要么用箭头函数显式只传你要的参数(arr.map(x => fn(x)),把 map 多传的 index/array 挡在外面),要么确认这个函数只接收一个参数(如 Number)才 point-free 直接传;对 parseInt 这类有 radix 第二参数的,务必 x => parseInt(x, 10) 显式指定十进制。

// 错误: 把多参数现成函数直接当回调, map 多传的参数被它误用
["1", "2", "3"].map(parseInt);        // ✗ [1, NaN, NaN](index 被当 radix)

// 正解1: 箭头函数显式只传要的参数(最通用, 最稳妥)
["1", "2", "3"].map(x => parseInt(x, 10));   // ✓ [1, 2, 3](只传 x, 明确十进制)

// 正解2: 用只接一个参数的函数, point-free 也安全
["1", "2", "3"].map(Number);          // ✓ [1, 2, 3](Number 只接一个参数)

// 正解3: 需要用到 index 时, 才显式接它, 别让它意外混进别的函数
arr.map((x, i) => `${i}: ${x}`);      // 明确知道并使用 index

// 同类警惕(多参数现成函数直接当回调):
["1", "2"].forEach(console.log);      // 会打印 元素+下标+数组三个
["1", "2"].forEach(x => console.log(x));     // ✓ 只打元素
promise.then(handleResult);           // then 传 value 一个参数, 一般 OK
//   但若 handleResult(value, opts) 有第二参数, 同样会被坑

// 默认原则: 不确定回调签名 vs 高阶方法传入参数对不对得上, 就用箭头函数包一层

这套做法的精髓,是在"高阶方法会传多个参数"和"现成函数能接多个参数"之间,用一层薄薄的箭头函数当"过滤器",只放你真正想传的参数过去,把多余的挡在外面。箭头函数 x => fn(x) 让 fn 永远只收到 x,无论 map 传了 index、array 还是别的;只接一个参数的函数(Number)则天生不受多传参数影响。代价只是多写几个字符,换来的是行为完全可控、不被看不见的额外参数带偏。不是图 point-free 简洁就把现成函数直接丢进去,而是用箭头函数明确地、只把你要的参数交给它。

【把现成函数当高阶方法回调, 我现在认死的几条】

1. map 给回调传三个参数: (element, index, array), 不只是元素

2. forEach/filter/some 等同理, 都传 (element, index, array)

3. point-free 直接传函数: 它会收到全部参数, 不止你想的那个

4. 函数恰好能接多参数(如 parseInt 的 radix)时, 多传的会被误用

5. 最稳妥: 箭头函数显式只传要的, arr.map(x => fn(x))

6. parseInt 务必 x => parseInt(x, 10)(指定十进制); 或用 Number

7. 只接一个参数的函数(Number)point-free 才安全; 不确定就包一层

第三件事:其他"额外的、没预期的参数被悄悄塞进去改变行为"的同类坑

顺着"调用方多传了你没预期的参数、而被调函数恰好接走并改变了行为"这条线,我把同类的坑都排查了一遍:

第一个,事件回调直接传带可选参数的函数。el.addEventListener("click", save),而 save(data) 的参数会收到 Event 对象,被当成 data 用,行为全乱;要 () => save(data)。

第二个,Promise.then 直接传双参数函数。.then(fn) 把 resolve 值传给 fn,若 fn 有第二参数(本想接配置),会拿不到、或拿到 undefined。

第三个,setTimeout 的额外参数。setTimeout(fn, 0, a, b) 会把 a、b 当参数传给 fn;反过来直接 setTimeout(fn) 也可能有平台相关的额外参数。

第四个,函数透传 ...args 给不期望那么多参数的下游。中间层 (...args) => downstream(...args) 把所有参数透传,下游若按位置用参数,多出来的会被它误读。

第四件事:point-free 直传 vs 箭头函数包一层——一张对照表

我把"直接传现成函数"和"箭头函数包一层"摆在一起对比,核心看"多传的参数会不会出事":

看清这张表,选择就有谱了:只接一个参数的函数(Number)可以 point-free 直传;能接多个参数的函数(parseInt)绝不能直传,必须用箭头函数 x => fn(x) 只传你要的;不确定就一律包一层箭头函数最稳。我这次踩坑,正是把能接 radix 的 parseInt 直接 point-free 传给 map,index 被当成了进制。箭头函数包一层多写几个字符,换来行为完全可控。

第五件事:我曾经对 map 回调想当然的几个误区

这次事故也把我对高阶回调的一堆"想当然"照了个底朝天:

这些误区的根子是同一个:我把"把函数 fn 当回调"想象成了"调用方只会按我心里想的那一个参数(当前元素)去调它",而没意识到调用方(map)实际会传一整组参数,而 fn 会照单全收、并按它自己的签名去解释这些参数。我和 map 对"该传几个参数"的预期不一致——我以为传一个,它传三个;而 parseInt 恰好能用上第二个,就把本不该它管的 index 当成了进制。把"我打算传给函数的参数"当成"函数实际会收到的参数",而忽略中间的调用方可能多塞参数,是这类 point-free 翻车的共同根源。

第六件事:point-free 传函数、排查"map 出一堆怪结果"时,我现在的自检习惯

现在每当我把现成函数直接当 map/forEach 等的回调、或排查"map 转出一堆 NaN/怪结果",我都会先按这张图问自己:

这张图的精髓,是"map 直传函数出怪结果先看那函数能不能接第二参数;能就是 map 的 index 被它误用、改用箭头函数只传要的"。设计就能接多参数的函数(parseInt)绝不 point-free 直传、用 x => fn(x, 固定参数)、只接一个参数的(Number)才可直传、不确定就包一层、排查就看那个回调函数的签名、是不是 map 多传的 index 被当成了它的第二参数。这套习惯,让我从"图简洁直接传函数"变成了"先核对它会被喂几个参数"——核心始终是:Array 的高阶方法(map、forEach、filter、some 等)在调用你传入的回调时都会传多个参数,对 map 是 (element, index, array)——当前元素、当前下标、原数组;当你 point-free 地把一个现成的函数直接当回调传进去(arr.map(fn) 而非 arr.map(x => fn(x))),这个函数会接收到全部这些参数而不只是你心里想的那个当前元素,如果这个函数只接收一个参数或多出来的参数它会忽略那没问题,但如果它恰好能接收并使用第二个第三个参数(像 parseInt 的 radix),那么 map 多传的参数就会被它接走悄悄改变它的行为——map(parseInt) 实际执行的是 parseInt(element, index)、把数组下标当成了进制,于是 parseInt("1",0)=1 碰巧对、parseInt("2",1) radix 1 无效返回 NaN、parseInt("3",2) 按二进制解析 3 不合法返回 NaN,得到 [1,NaN,NaN];正解是把现成函数当回调只有在它的参数签名和高阶函数实际传入的参数在你需要的范围内对得上时才安全,最稳妥也最不容易出错的做法是用箭头函数显式地只传你要的参数 arr.map(x => fn(x))——这样无论 map 传多少个参数都只有 x 这一个被传给 fn、多余的 index/array 被箭头函数挡在外面绝不会被误用,对 parseInt 正确写法是 arr.map(x => parseInt(x, 10)) 或直接用 arr.map(Number)(Number 只接一个参数);当你把一个能接收多个参数的现成函数直接交给一个会传入多个参数的高阶机制(map、事件回调、Promise then 等)时要警惕那些你没打算传却被自动传进去的额外参数——它们可能被那个函数接走并改变行为,要么确认参数签名严格匹配要么用一层薄薄的包装(箭头函数)显式地只传你真正想传的那些参数把多余的挡在外面。

我立下的几条规矩

这场"map(parseInt) 转出一堆 NaN"的事故,换来了我把现成函数当回调时,刻进骨子里的几条铁律:

1. map 给回调传三个参数 (element, index, array),不只是元素。
2. forEach/filter/some 等同理,都传 (element, index, array)。
3. point-free 直接传函数:它会收到全部参数,不止你想的那个。
4. 函数恰好能接多参数(如 parseInt 的 radix)时,多传的会被误用。
5. 最稳妥:箭头函数显式只传要的,arr.map(x => fn(x))。
6. parseInt 务必 x => parseInt(x, 10)(指定十进制);或用 Number。
7. 只接一个参数的函数 point-free 才安全;不确定就包一层。

附:我现在 point-free 传函数的"显式适配 + 解析工具"骨架

这是我现在把现成函数当回调固定套的小工具——把这次踩坑的教训(箭头函数显式只传要的、解析数字封装好进制、警惕多参数函数直传)固化成几个封装,让"map(parseInt) 出一堆 NaN"那种坑再不会埋进代码:

// 工具1: 安全的字符串转数字(封装好进制和校验, 别裸用 parseInt 当回调)
const toInt = (s) => {
    const n = parseInt(s, 10);          // 明确十进制, 只接一个入参
    return Number.isNaN(n) ? null : n;  // 解析失败给 null, 不混入 NaN
};
const toNum = (s) => {
    const n = Number(s);                // Number 只接一个参数
    return Number.isNaN(n) ? null : n;
};

// 用法: 这些都是单参数函数, point-free 直传也安全
["1", "2", "3"].map(toInt);             // [1, 2, 3] ✓
["1", "x", "3"].map(toInt);             // [1, null, 3] ✓ 解析失败显式 null

// 工具2: unary —— 把任意函数包成"只接一个参数", 挡掉高阶方法多传的
const unary = (fn) => (x) => fn(x);

["1", "2", "3"].map(unary(parseInt));   // 仍不对! parseInt 需要 radix
// 所以 parseInt 要的是"固定第二参数", 用专门的包装:
const radix = (r) => (s) => parseInt(s, r);
["1", "2", "3"].map(radix(10));         // [1, 2, 3] ✓

// 工具3: 真要 point-free 直传现成函数前, 先确认它的参数个数
function safeCallback(fn) {
    // fn.length 是声明的形参个数, >1 的现成函数别裸传给 map(会被多塞参数)
    if (fn.length > 1) {
        console.warn(`${fn.name} 接收多个参数, 别直接当 map 回调, 用箭头函数包一层`);
    }
    return fn;
}

// 默认原则: 不确定就箭头函数包一层, 只传你要的
["1","2","3"].map(x => parseInt(x, 10));  // 永远对、最清晰

这套工具把我这次的教训钉死在了代码里:把"字符串转数字"封装成 toInt/toNum(内部锁死十进制、解析失败给 null 而非 NaN、且只接一个参数)这样的单参数函数,point-free 直传也安全;需要固定第二参数(如 parseInt 的进制)就用 radix(10) 这种返回单参数函数的包装;实在要直传现成函数,先用 fn.length 确认它只接一个参数、多于一个就警告;不确定一律箭头函数包一层只传你要的。这样,交给 map 的回调永远只收到我想给的参数,而不再是当初那个"parseInt 被 map 多塞的 index 当成进制、转出一堆 NaN"的局面。把"核对接口衔接处的参数约定、用显式适配只传你要的参数"这个道理,沉淀成传函数的固定骨架,这是我对这次"[1, NaN, NaN]"最实在的交代——毕竟,把活儿交给别人去调用时,得自己先把"到底给它喂几样东西"说清楚,而不是任由中间人多塞、任由它乱接。

写在最后

回头看,这场由"map(parseInt)"引发的"一堆 NaN"事故,真正教给我的,远不止"用箭头函数包一层"这一个技巧。它让我对"当我们把一个'函数'交给某个'会去调用它的机制'(高阶函数、事件系统、回调框架)时,'这个机制实际会传给函数几个参数' 和 '我们以为它会传几个',常常不是一回事;而那个被交出去的函数,会照单全收所有传给它的参数、并按它自己的签名去解释这些参数——于是那些'我们没打算传、却被悄悄塞进去'的多余参数,一旦恰好落在函数某个有意义的形参位置上,就会不动声色地改变它的行为",有了一次刻骨的体会。我栽跟头,是因为我把"我打算交给函数的参数(一个元素)"当成了"函数实际会收到的参数",忽略了中间那个调用者(map)会按它自己的规矩多塞参数——我以为 map(parseInt) 就是"逐个对元素调 parseInt",心里只装着"元素"这一个参数;可 map 有它自己的约定:每次调回调都奉上 (元素, 下标, 数组) 三样东西;而 parseInt 也有它自己的签名:第二个参数是进制;于是 map 慷慨递上的"下标",被 parseInt 当成了"进制"笑纳了——两个我各自都熟悉、都没错的约定,在我没留意的衔接处对错了位,酿成一片 NaN。这让我领悟到一个关于"接口衔接处的参数约定"的深刻认知:当两个独立的部分(一个负责调用、一个负责被调用)在一个接口处衔接时,真正决定行为的,不是任何一方单独的意图,而是双方对"这里传/收几个参数、各是什么含义"的约定是否真正对齐;调用方"多给"的参数不会凭空消失,被调方会按自己的签名去接收和解释它们——如果被调方恰好有个形参在那个位置、且含义不同,这个"多给的、被错解的参数"就会悄悄改变结果,而且因为双方各自看都"没错"、衔接处又没有报错,这种错位极其隐蔽;所以把一个函数"裸传"给一个会调用它的机制,本质是在做一个"赌双方参数约定恰好对齐"的隐式假设;消除这个隐患的办法,是在衔接处加一层显式的、薄薄的适配(箭头函数 x => fn(x)),由你亲手规定"到底把哪几个参数、以什么顺序交给它",而不是把这个关键的对接,交给两边碰巧一致的运气。这给了我一种看待"一切'把函数交给某机制去调用'之事"时的清醒:每当我把一个现成函数交给一个会调用它的高阶机制(map、事件监听、then、回调注册)时,要追问"这个机制实际会传几个参数给我的函数?我的函数能接几个、会怎么解释它们?多传的参数会不会被它接走改变行为?"——在不确定双方参数约定是否对齐时,用一层箭头函数显式规定只传你要的参数,别裸传函数去赌两边碰巧一致;"核对接口衔接处的参数约定、用显式适配只传你要的参数",是用对 map 等高阶方法、也是安全衔接一切回调的关键。认清 map 传三个参数、parseInt 把 index 当进制、point-free 直传要核对签名——这,是我用一次"map(parseInt) 转出一堆 NaN"的事故,换来的、关于 JavaScript、也关于如何对齐接口衔接处参数约定的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次想 arr.map(someFn) point-free 一把时,先想一句"someFn 会不会用到 map 多传的 index?要不要写成 x => someFn(x)?",那我对着那个 [1, NaN, NaN] 发懵的大半天,就值了。

—— 别看了 · 2026