第 2 章 JavaScript 函数式编程 — 全书代码的风格宪章Copy Anchor Link

这一章讲什么: 函数式编程(FP)是什么、JavaScript 凭什么算函数式语言、 以及怎么写出「纯」的函数。它在全书链条里的位置:风格宪章——后面每一章的 数据结构实现都默认遵守这里立的规矩:优先纯函数、不改输入、用高阶函数做包装。 读完本章,你看后面任何一段实现代码,都能说出它为什么长那样。

1. 顶层全景Copy Anchor Link

  为什么用 FP ──→ JS 算不算函数式语言 ──→ 四块基石 ──→ 纯度怎么守 ──→ 守不住怎么办
     │                │                    │               │              │
  五个诉求          没有精确定义,          ① 函数是一等公民    不读全局变量    状态当参数传进来
  (好懂/好修/        按「支持常见 FP        ② 声明式数组方法      不存内部状态    (避免状态)
   好测/模块化/       特性」算,JS 算        ③ 高阶函数          不改传入参数    不纯的东西当参数传
   可复用)                              ④ 纯函数                            (注入模式)

  图说:前半章讲「是什么、有什么好」,后半章讲「怎么做到、做不到时怎么补救」。

2. 主线例子:一个数组、一组谓词,走完整个声明式工具箱Copy Anchor Link

原书在这一章几乎全程用同一个数组,我们照原书把它当主线例子¹:

let myArray = [22, 9, 60, 12, 4, 56];
const under21 = (value) => value < 21;   // 谓词:「是否小于 21」
const equal21 = (value) => value === 21; // 谓词:「是否恰好 21」

谓词(predicate) 这个词先解释:它是一个返回 true/false 的函数, 用来回答「这个元素符不符合条件」。under21 就是「小于 21 吗」。 下面每一步都对这同一个数组操作,每一步旁边写出具体结果:

第 ① 步 过滤 .filter()——选出符合条件的,留新数组:

myArray.filter(under21);  // [9, 12, 4]

22 不满足(不小于 21)、9 满足、60 不满足、12 满足、4 满足、56 不满足。 结果是新数组 [9, 12, 4],原数组一动没动²。

第 ② 步 查找 .find() / .findIndex()——找第一个满足条件的:

myArray.find(under21);      // 9   第一个小于 21 的元素
myArray.findIndex(under21); // 1   它在数组中的位置(从 0 数)
myArray.find(equal21);      // undefined  没有恰好 21 的
myArray.findIndex(equal21); // -1         同上,位置惯例返回 -1

第 ③ 步 整体判断 .some() / .every():

myArray.some(under21);   // true   至少有一个小于 21
myArray.every(under21);  // false  并非所有元素都小于 21
myArray.some(equal21);   // false
myArray.every(equal21);  // false

第 ④ 步 变形 .map()——一对一换成新值:

myArray.map((x) => 10 * x);  // [220, 90, 600, 120, 40, 560]

每个元素各自乘 10,还是新数组。

第 ⑤ 步 归约 .reduce()——把全数组揉成一个值:

myArray.reduce((a, v) => a + v, 0);  // 163

a 是累加器(accumulator,从 0 出发),v 是当前元素。走一遍: a=0 加 22 得 22,加 9 得 31,加 60 得 91,加 12 得 103,加 4 得 107,加 56 得 163³。

一步进阶:一次算出「和」和「个数」,把累加器升级成对象:

myArray.reduce((a, v) => ({ s: a.s + v, c: a.c + 1 }), { s: 0, c: 0 });
// { s: 163, c: 6 }  —— 和 163,共 6 个元素

第 ⑥ 步 遍历 .forEach()——只要副作用(比如累加到一个外部变量)时:

let sum = 0;
myArray.forEach((v) => { sum += v; });
sum;  // 163

走完六步,注意三件事:没有一步写过 for 循环;没有一步改过 myArray 本身; 每一步都是「说清楚要什么」,而不是「指挥机器一步步怎么做」——这就是下一节的主题。

3. 核心原理Copy Anchor Link

3.1 为什么用 FP:五个诉求Copy Anchor Link

作者开头就问:你想要代码有什么品质?他列了五条,每条都对应 FP 的一个具体机制⁴:

作者随即自己泼了冷水:面向对象的代码同样能做到这些,FP 不是银弹; 他的立场是走中间路线,「深思熟虑的均衡混合通常是最好的解」⁵。 这句话要当真——后面章节该用对象的地方照样用对象(第 13 章的类就是)。

3.2 JavaScript 算不算函数式语言Copy Anchor Link

讨论这个问题的人通常举 Haskell、Erlang、Scala,没人带 JavaScript。 作者的应对很务实:「函数式语言」从来没有精确定义,那么本书就自定一个口径: 只要支持常见的 FP 特性,就算函数式语言⁶。 按这个口径,JavaScript 支持:函数作为一等公民、数组函数、纯函数、高阶函数、递归, 并能避开副作用——算。他还补了一句历史注脚:FP 不是新潮玩意,还在广泛使用的 第二老的语言 LISP(1958 年,仅比 FORTRAN 晚一年)完全建立在 FP 上⁷。

3.3 基石一:函数是一等公民Copy Anchor Link

一等公民(first-class) 是个精确的说法:函数可以像数字、字符串一样—— 存进变量、当参数传给别的函数、作为别的函数的返回值⁸。

书里给的例子是前端常见的 API 调用:axios.get("url").then((response) => { … })。 .then() 的参数是一个函数,传它的方式和传一个数字或数组完全一样。 第 12 章会把这个手法用在二叉树遍历上:

const preOrder = (tree, visit = (x) => console.log(x)) => {
  if (tree !== null) {
    visit(tree.key);
    preOrder(tree.left, visit);
    preOrder(tree.right, visit);
  }
};

遍历树的时候「访问每个节点」要干什么?不写死,由调用方传一个 visit 函数进来; 不传就默认是「打印出来」。算法的骨架与对节点的具体动作,就此分离—— 这是全书反复出现的设计模式:第 6 章排序的比较、第 10 章列表的操作,全都是 「骨架固定、动作注入」。

顺带定义:收函数当参数、或返回函数的,叫高阶函数(higher-order function); 不收不返的,叫一阶函数。所有带回调的函数和所有数组方法,都是高阶函数⁹。

3.4 基石二:声明式编程与数组方法Copy Anchor Link

声明式(declarative)对照命令式(imperative):命令式一步步指挥 「初始化空数组、设 i 为 0、循环、判断、push」;声明式只说 「给我过滤后的新数组」,怎么循环、怎么收集,是方法内部的事¹⁰。

第 2 节那条主线已经演示了六个方法的用法。这里把「什么时候用哪个」收成一张表 (findLast/findLastIndex 是从尾往前找的近年新增版本)¹¹:

两个提醒。第一,找特定值而不用条件时,.includes()、.indexOf()、 .lastIndexOf() 更直接,只是它们不接受任意条件,不如上表灵活¹²。 第二,.reduce() 最好总是给初值:对空数组归约不给初值会运行时报错¹³。

关于性能争议,书里的态度原话收进脚注:即使数组方法真比手写循环慢,也无关紧要—— 除非你实测确认瓶颈在此,否则写更长、更容易出 bug 的循环没有意义¹⁴。

3.5 基石三:纯函数与副作用Copy Anchor Link

纯函数(pure function):只依赖自己的参数、不产生任何副作用的函数。 「副作用」指:改程序状态、改变量、改对象——凡是「除了返回值之外还动了别的地方」, 都算¹⁵。

纯函数的好处,书里给了两条,都很硬:

1. 同样输入必得同样输出——结果不依赖任何外部变量,外部变了也不会悄悄变;
2. 调用它时不用提心吊胆——不用担心哪里的状态被碰坏,注意力只在参数上。

反过来说,纯函数不能依赖这些东西:随机数、当前时间、I/O(输入输出)的结果—— 因为它们都是「函数之外的变量」¹⁶。

副作用有三个主要来源,书里一节一个,这也是后半章的骨架:

来源一:全局状态。 函数读了外部的共享变量,就不再纯。 调试会变难:要理解函数为什么返回这个值,你得搞清整个程序的历史状态¹⁷。

来源二:内部状态。 函数体内有跨调用存活的变量,也会让「同样输入」得到不同输出。 书里由此解释了函数式程序员为什么本能地避开对象:对象把数据存起来供方法使用, 方法的结果就可能依赖内部属性,纯度自动失守¹⁸。

来源三:修改参数。 JavaScript 里,基本类型(数字、字符串等)按值传参, 而对象和数组按引用传参——函数里改参数,改的就是调用方手里的原物。 最坑的是 JavaScript 自带一堆「按定义就改输入」的方法:myArray.sort()、 pop()、splice() 全都地动原数组¹⁹。 书里还点了一个容易踩的坑:想从右往左归约,有人先 .reverse() 再 .reduce(), 结果原数组被翻了个面——副作用。近年标准补了不改输入的版本: toSorted()、toReversed()、toSpliced()(补充:这些是 ES2023 新增, 书中已提及)²⁰。

本来就纯不了的函数怎么办:调 API 拿每日新闻、用 Math.random() 掷随机数、 读当前时间、做任何 I/O——这些函数的整个意义就在于「每次结果不一样」。 console.log 也算:它不返回有用值,但改了屏幕上的东西²¹。 所以下一节的主题不是「消灭不纯」,而是「缩小不纯的范围」。

3.6 基石四(补救):高阶函数做包装Copy Anchor Link

包装(wrapping) 是高阶函数最实用的用法:造一个新函数,保留原函数的全部功能, 外面附加一点行为,而原函数一行不动。

书里完整的例子是给函数加日志。直接改原函数的风险:它有多个 return, 你得每个都改,还可能误伤。包装器的写法:

const addLogging = (fn) => (...args) => {
  console.log("Entering", fn.name, "with", ...args);
  const toReturn = fn(...args);
  console.log("Exiting", fn.name, "returning", toReturn);
  return toReturn;
};

const sum2 = (a, b) => { console.log("Calculating..."); return a + b; };
addLogging(sum2)(22, 9);
// Entering sum2 with 22 9
// Calculating...
// Exiting sum2 returning 31

走一遍:addLogging(sum2) 返回一个新函数;调它并给 (22, 9), 新函数先打印「进入 sum2,参数 22 和 9」,再把 22, 9 转给原 sum2, 它打印「Calculating...」并算出 31,新函数接着打印「返回 31」,把 31 交给调用者。 sum2 本身从头到尾没被碰过²²。

这个模式的全书戏份很重:第 5 章的记忆化、本章习题的计时器,都是它的变奏。 判断标准一句话:「附加行为」和「原逻辑」分离,附加部分可以随时拆下来。

3.7 补救一:状态当参数传来传去Copy Anchor Link

如果一个函数需要全局状态,规矩是:需要哪些状态,就当参数传进来; 如果它需要更新状态,不许自己改,而是把新状态算出来、作为返回值交出去, 由调用方决定去不去更新全局²³。

这一下同时解决了测试难题:测试时不用先布置全局环境,喂初始状态、验返回的新状态即可。

3.8 补救二:注入模式Copy Anchor Link

对于「真的需要不纯操作」的场合(发请求、掷随机数),书里给的手法叫注入(injection): 不纯的那个动作本身作为函数参数传进来:

const getData = (url) => axios.get(url);  // 真正发请求的函数
doSomething(a, b, c, getData);            // 把它注进去
function doSomething(x, y, z, getter) {
  // ...用 getter("/some/url") 代替直接 axios.get(...)
}

被注入方的内部不再直接碰全局的 axios,于是它自己变纯了——不纯被挤到了 调用现场。测试时注一个假函数(mock)进去,不用真的发请求²⁴。

书里点破了这层窗户纸:这和「状态当参数」其实是同一招—— 「直接用 axios.get() 本质是在用全局对象的方法,注入一个参数,函数就不必碰全局」。

3.9 声明式为什么更安全:把循环的 bug 清单摊开看Copy Anchor Link

作者没有逐一枚举手写循环容易错在哪,但把「命令式写法」的样板摊出来, bug 清单自己就显形了。同一个过滤任务,两种写法并排:

// 命令式:自己指挥每一步
let newArray = [];
for (let i = 0; i < myArray.length; i++) {
  if (myArray[i] < 21) {
    newArray.push(myArray[i]);
  }
}

// 声明式:只说要什么
let newArray = myArray.filter(under21);

四行变一行,同时消掉了手写循环的全部经典出错点(补充,不在书里,来自通用知识; 原书只给了「更短、更少机会引入 bug」的结论²⁵):

书里那句「代码更短,所以引入 bug 的机会更少」( fewer chances of introducing bugs)说的就是这个对照²⁵。 还有个词值得记:.map() 这类方法产出新数组而不改原数组, 所以用它写的函数天然是 3.5 节意义上的纯函数——声明式与纯度在这里合流。

3.10 .reduce() 的两种步态:数字累加器与对象累加器Copy Anchor Link

第 2 节第 ⑤ 步只走了数字版,这里把对象版也走完,顺便说清 reduce 的通用形状。 通用形状是:累加器 + 当前元素 → 新累加器,反复应用,直到数组耗尽:

  初值 {s:0, c:0}
    │ 元素 22:新累加器 {s:0+22, c:0+1} = {s:22, c:1}
    │ 元素  9:{s:31, c:2}
    │ 元素 60:{s:91, c:3}
    │ 元素 12:{s:103, c:4}
    │ 元素  4:{s:107, c:5}
    │ 元素 56:{s:163, c:6}
    ▼
  结果 {s:163, c:6}  —— 和 163,个数 6

  图说:每一步都是「旧累加器 + 一个元素 = 新累加器」。累加器是什么类型,由初值决定。
  初值是数字就揉出数字,初值是对象就能同时累计多个量。

这个「累加器形状」在全书会反复出现:第 6 章的一些排序、第 17 章图算法里的距离表, 本质都是 reduce 思路的展开。.reduceRight() 唯一的差别是从最后一个元素开始 往前走;书里提醒:别用「先 .reverse() 再 .reduce()」来 emulate 它—— reverse 就地改数组,是教科书级的副作用事故(3.5 节来源三)²⁶。

3.11 注入模式再走一步:测试为什么是主要受益者Copy Anchor Link

注入的例子 3.8 节给了骨架,这里把它与测试的关系说透,因为这是书里 「simplifies unit testing」的实际含义²⁷:

没有注入时,doSomething 内部直接 axios.get()——单测一跑,真的发出 HTTP 请求: 慢、依赖网络、结果每天不同,测试没法写断言。注入之后:

// 生产环境:注入真的
doSomething(a, b, c, (url) => axios.get(url));
// 测试环境:注入假的
doSomething(a, b, c, (url) => Promise.resolve({ data: "固定假数据" }));

被测函数的输入完全由测试控制,输出因此可断言。「不纯挤到边界上」的准确含义是: 不纯挤到「组装参数的那个地方」——而那个地方正是测试可以接管的地方。 这也是第 18 章函数式数据结构的思想先声:把「变化」集中到边界,内部全是纯的。

3.12 本章规矩在后续章节的落点Copy Anchor Link

把「风格宪章」说实:本章立的规矩,后面具体落在哪。

这张表是「宪章」二字的证据:后面章节不是「风格相似」,而是逐条执行。

4. 作者的判断与证据Copy Anchor Link

• 「中间路线」是明确立场,不是骑墙:作者明说 FP 不是银弹、均衡混合最好, 并以「后面该用 OOP 处照样用」贯穿全书作证(第 13 章的类、第 3 章的对象实现)⁵。
• 「函数式语言无精确定义」是文献事实,作者的应对是自定义操作口径(支持常见 FP 特性就算), 并立即用它论证 JS 合格——逻辑自洽,但读者要知道这个「算」是本书的口径,不是学界共识⁶。
• 性能态度有明确条件句:「即使数组方法更慢也没关系」的前提是「除非实测它就是瓶颈」—— 这是工程经验之谈,无数据支撑,书里也没打算给数据¹⁴。
• 习题是本章证据链的一部分:8 道习题(2.1–2.8)逐个逼问概念边界——纯度判别、 包装器容错、.map(parseInt) 的经典坑、用 .findIndex 重写 .some/.every—— 答案在书末,我们把要点收在第 5 节。

判断(我们的,不是书里的): 本章真正的贡献不是「FP 很好」这个结论 (这类结论满大街都是),而是把 FP 落成了 JavaScript 里可执行的检查清单: 读全局了吗?存内部状态了吗?改参数了吗?改不了就注进来。 这四问比任何范式宣言都好用,而且直接决定了第 6、10、18 章代码的形状。 如果错,会错在: 这套清单对「算法教学代码」是对的,但对 I/O 密集的真实应用, 全面遵守它的成本可能超过收益——作者其实也承认(中间路线),只是没有量化成本边界。

5. 边界与局限Copy Anchor Link

• 不教你 Haskell 式类型系统:没有代数数据类型、模式匹配、单子这些「真·函数式」 硬核概念;全书的 FP 就是「JS 里的纯函数 + 高阶函数」这一实用子集。
• 并发、异步不在本章范围:.then() 只是当一等公民的例子带了一下, Promise、async/await 的系统讲解没有(第 1 章特性清单也没提)。
• 「比循环慢没关系」缺数据:没有 benchmark,只有工程经验;在超热循环里 (百万级元素的归约),方法调用的开销是真实存在的——这是补充(不在书里,来自通用知识)。
• 答案部分的取舍:书末「Chapter 2」答案是习题 2.1–2.8 的解答,其中 2.2/2.3 (日志/计时包装器)有完整代码,2.4(.map(parseInt) 之谜)的解释尤其值得看—— 我们在 6.1 节展开。

5.1 习题答案里最有教学价值的三处Copy Anchor Link

① 2.1 纯还是不纯? 题:const PI = 3.14159265358979; const circumference = (r) => 2 * PI * r; 用了全局变量 PI,形式上是「不纯」。答案的说法很老练:既然 PI 是常量、 又有 const 守着没人改得了,「可以勉强接受」;但最好的解法是根本不造这个外部变量, 直接用 Math.PI——纯度的边界案例,标准答案是不留边界,直接消掉²⁸。

② 2.4 .map(parseInt) 之谜。 [1,2,4,8,16,32].map(parseInt) 得到 [1, NaN, NaN, NaN, 1, 17]——为什么?答案拆得很细:.map() 给回调传三个参数 (当前元素、它的下标、整个数组);parseInt 收两个参数(要解析的串、进制), 第三个被忽略,第二个被当成了进制。于是:parseInt("1", 0)→1(0 按 10 处理); parseInt("2", 1)→NaN(一进制不存在);parseInt("4", 2)→NaN(二进制没有 4); parseInt("8", 3)→NaN;parseInt("16", 4)→1(4 进制里 16 是 1×4+6?不,等等—— 4 进制只允许数字 0–3,这里答案原文说 16 被当四进制解析……实际上 parseInt("16",4) 取 到第一个非法字符为止,得 1);parseInt("32", 5)→17(5 进制:3×5+2=17)²⁹。 教训:回调签名对不上时,JS 不会报错,只会静默地拿多余参数干别的——这正是 3.5 节 「改参数/暗参数」风险的一个干净变体。

③ 2.6–2.7 互相重写。 .none() 可以一行造出来:没有元素满足谓词 ⟺ 所有元素都满足 「谓词取反」——people.every(negate(isAdult)),其中 negate = (fn) => (...args) => !fn(...args); 而 .some() 本身也能用 .findIndex() 重写:findIndex(谓词) !== -1 就是 some, findIndex(取反的谓词) === -1 就是 every³⁰。这组答案的意思:这些方法不是 六个黑箱,而是同一个「按谓词扫描」骨架的六个出口。

5.2 答案走读:计时包装器 addTiming(习题 2.3)Copy Anchor Link

习题 2.2/2.3 的答案代码是全书包装器模式最完整的样板,值得逐行走一遍。 addTiming 在 addLogging 之上只加一样东西:计时³¹:

const {performance} = require("perf_hooks");   // Node.js 里要手动引入 performance

const addTiming = (fn) => (...args) => {
  const output = (text, name, tStart, tEnd) =>
    console.log(`${name} - ${text} - Time: ${tEnd - tStart} ms`);

  const tStart = performance.now();            // 调用前记下时刻
  try {
    const valueToReturn = fn(...args);         // 原样调用原函数
    output("normal exit", fn.name, tStart, performance.now());
    return valueToReturn;                      // 返回值原样上交
  } catch (thrownError) {
    output("exception thrown", fn.name, tStart, performance.now());
    throw thrownError;                         // 异常也原样重抛
  }
};

逐行走完要点有三个。第一,返回值和异常都原样透传——包装器对调用方完全透明, 调用方感觉不到自己用的是包装后的函数;这正是「包装」的合格线。 第二,两条出路(正常返回/抛异常)都要计时,只计一半会让异常路径的耗时永远成谜。 第三,performance.now() 是浏览器和 Node 都有的高精度计时器, Node 端要 require("perf_hooks") 引入——这个细节答案里专门注了一行。 把 addTiming(quicksort)(bigArray) 和第 6 章排序章节连起来用, 就是原书「性能」主题(第 4 章)的最小测量工具。

5.3 答案走读:.map(parseInt) 六连错全表(习题 2.4)Copy Anchor Link

这个坑值得把六个元素的遭遇列成一张全表(依据书末答案的逐条解释²⁹):

所以输出是 [1, NaN, NaN, NaN, 1, 17]——没有任何一步报错, 每一步都是「合法地」拿错了参数。这个例子在全书的教学价值在于: 它把 3.4 节那句「回调签名对不上时 JS 不报错」从警告变成了你见过一次的现场。

6. 可带走的Copy Anchor Link

1. 五个诉求是 FP 的卖点:好懂、好维护、好测试、模块化、可复用——但作者明说 OOP 同样能做到,别当宗教。

2. 一等公民 = 函数能进变量、能当参数、能当返回值;高阶函数 = 收函数或返回函数的函数。

3. 谓词是返回布尔的函数;.filter/.find/.some/.every 全是「按谓词扫描」一家子。

4. .map 一对一变形、.reduce 全组揉成一个值(记得给初值,空数组才不炸)。

5. 纯函数检查清单:读全局?存内部状态?改参数?——三问都答「否」才算纯。

6. 对象和数组按引用传参,函数里改它们就是改调用方的原物;sort()/splice() 这类方法本来就地改动。

7. 包装器模式:addLogging 那种「原函数不动、套一层附加行为」的写法,是调试与计时、记忆化的通用骨架。

8. 守不住纯度时:状态当参数传进来、新状态当返回值交出去;不纯的动作当函数注进来(注入模式),测试时换假函数。

9. .map(parseInt) 的坑记住:回调会收到 (元素, 下标, 数组) 三个参数——签名对不上是静默灾难。

10. 谓词三兄弟的关系:some = findIndex ≠ -1;every = 取反后 findIndex = -1;none = every 加取反——六个数组方法是一个骨架的六个出口(习题 2.7 答案)。

7. 原文地图Copy Anchor Link