翻译连载 | 第 9 章：递归（下）－《JavaScript轻量级函数式编程》 |《你不知道的JS》姊妹篇

• 原文地址：Functional-Light-JS
• 原文做者：Kyle Simpson－《You-Dont-Know-JS》做者

关于译者：这是一个流淌着沪江血液的纯粹工程：认真，是 HTML 最坚实的梁柱；分享，是 CSS 里最闪耀的一瞥；总结，是 JavaScript 中最严谨的逻辑。通过捶打磨练，成就了本书的中文版。本书包含了函数式编程之精髓，但愿能够帮助你们在学习函数式编程的道路上走的更顺畅。比心。

译者团队（排名不分前后）：阿希、blueken、brucecham、cfanlife、dail、kyoko-df、l3ve、lilins、LittlePineapple、MatildaJin、冬青、pobusama、Cherry、萝卜、vavd317、vivaxy、萌萌、zhouyao

第 9 章：递归（下）

栈、堆

一块儿看下以前的两个递归函数 isOdd(..) 和 isEven(..)：

function isOdd(v) {
	if (v === 0) return false;
	return isEven( Math.abs( v ) - 1 );
}

function isEven(v) {
	if (v === 0) return true;
	return isOdd( Math.abs( v ) - 1 );
}
复制代码

若是你执行下面这行代码，在大多数浏览器里面都会报错：

isOdd( 33333 );			// RangeError: Maximum call stack size exceeded
复制代码

这个错误是什么状况？引擎抛出这个错误，是由于它试图保护系统内存不会被你的程序耗尽。为了解释这个问题，咱们须要先看看当函数调用时JS引擎中发生了什么。

每一个函数调用都将开辟出一小块称为堆栈帧的内存。堆栈帧中包含了函数语句当前状态的某些重要信息，包括任意变量的值。之因此这样，是由于一个函数暂停去执行另一个函数，而另一个函数运行结束后，引擎须要返回到以前暂停时候的状态继续执行。

当第二个函数开始执行，堆栈帧增长到 2 个。若是第二个函数又调用了另一个函数，堆栈帧将增长到 3 个，以此类推。“栈”的意思是，函数被它前一个函数调用时，这个函数帧会被“推”到最顶部。当这个函数调用结束后，它的帧会从堆栈中退出。

看下这段程序：

function foo() {
	var z = "foo!";
}

function bar() {
	var y = "bar!";
	foo();
}

function baz() {
	var x = "baz!";
	bar();
}

baz();
复制代码

来一步步想象下这个程序的堆栈帧：

注意： 若是这些函数间没有相互调用，而只是依次执行 -- 好比前一个函数运行结束后才开始调用下一个函数 baz(); bar(); foo(); -- 则堆栈帧并无产生；由于在下一个函数开始以前，上一个函数运行结束并把它的帧从堆栈里面移除了。

因此，每个函数运行时候，都会占用一些内存。对多数程序来讲，这没什么大不了的，不是吗？可是，一旦你引用了递归，问题就不同了。 虽然你几乎确定不会在一个调用栈中手动调用成千（或数百）次不一样的函数，但你很容易看到产生数万个或更多递归调用的堆栈。

当引擎认为调用栈增长的太多而且应该中止增长时候，它会以主观的限制来阻止当前步骤，因此 isOdd(..) 或 isEven(..) 函数抛出了 RangeError 未知错误。这不太多是内存接近零时候产生的限制，而是引擎的预测，由于若是这种程序持续运行下去，内存会爆掉的。因为引擎没法判断一个程序最终是否会中止，因此它必须作出肯定的猜想。

引擎的限制因状况而定。规范里面并无任何说明，所以，它也不是 必需的。但若是没有限制的话，设备很容易遭到破坏或恶意代码攻击，故而几乎全部的JS引擎都有一个限制。不一样的设备环境、不一样的引擎，会有不一样的限制，也就没法预测或保证函数调用栈能调用多少次。

在处理大数据量时候，这个限制对于开发人员来讲，会对递归的性能有必定的要求。我认为，这种限制也多是形成开发人员不喜欢使用递归编程的最大缘由。 遗憾的是，递归编程是一种编程思想而不是主流的编程技术。

尾调用

递归编程和内存限制都要比 JS 技术出现的早。追溯到上世纪 60 年代，当时开发人员想使用递归编程并但愿运行在他们强大的计算机的设备，而所谓强大计算机的内存，尚远不如咱们今天在手表上的内存。

幸运的是，在那个但愿的原野上，进行了一个有力的观测。该技术称为 尾调用。

它的思路是若是一个回调从函数 baz() 转到函数 bar() 时候，而回调是在函数 baz() 的最底部执行 -- 也就是尾调用 -- 那么 baz() 的堆栈帧就再也不须要了。也就意谓着，内存能够被回收，或只需简单的执行 bar() 函数。 如图所示：

尾调用并非递归特有的；它适用于任何函数调用。可是，在大多数状况下，你的手动非递归调用栈不太可能超过 10 级，所以尾调用对你程序内存的影响可能至关低。

在递归的状况下，尾调用做用很明显，由于这意味着递归堆栈能够“永远”运行下去，惟一的性能问题就是计算，而再也不是固定的内存限制。在固定的内存中尾递归能够运行 O(1) （常数阶时间复杂度计算）。

这些技术一般被称为尾调用优化（TCO），但重点在于从优化技术中，区分出在固定内存空间中检测尾调用运行的能力。从技术上讲，尾调用并不像大多数人所想的那样，它们的运行速度可能比普通回调还慢。TCO 是关于把尾调用更加高效运行的一些优化技术。

正确的尾调用 (PTC)

在 ES6 出来以前，JavaScript 对尾调用一直没明确规定（也没有禁用）。ES6 明确规定了 PTC 的特定形式，在 ES6 中，只要使用尾调用，就不会发生栈溢出。实际上这也就意味着，只要正确的使用 PTC，就不会抛出 RangeError 这样的异常错误。

首先，在 JavaScript 中应用 PTC，必须以严格模式书写代码。若是你之前没有用过严格模式，你得试着用用了。那么，您，应该已经在使用严格模式了吧！？

其次，正确 的尾调用就像这个样子：

return foo( .. );
复制代码

换句话说，函数调用应该放在最后一步去执行，而且无论返回什么东东，都得有返回（ return ）。这样的话，JS 就再也不须要当前的堆栈帧了。

下面这些 不能 称之为 PTC：

foo();
return;

// 或

var x = foo( .. );
return x;

// 或

return 1 + foo( .. );
复制代码

注意： 一些 JS 引擎 可以 把 var x = foo(); return x; 自动识别为 return foo();，这样也能够达到 PTC 的效果。但这毕竟不符合规范。

foo(..) 运行结束以后 1+ 这部分才开始执行，因此此时的堆栈帧依然存在。

不过，下面这个 是 PTC：

return x ? foo( .. ) : bar( .. );
复制代码

x 进行条件判断以后，或执行 foo(..)，或执行 bar(..)，不论执行哪一个，返回结果都会被 return 返回掉。这个例子符合 PTC 规范。

为了不堆栈增长，PTC 要求全部的递归必须是在尾部调用，所以，二分法递归 —— 两次（或以上）递归调用 —— 是不能实现 PTC 的。咱们曾在文章的前面部分展现过把二分法递归转变为相互递归的例子。也许咱们能够试着化整为零，把多重递归拆分红符合 PTC 规范的单个函数回调。

重构递归

若是你想用递归来处理问题，却又超出了 JS 引擎的内存堆栈，这时候就须要重构下你的递归调用，使它可以符合 PTC 规范（或着避免嵌套调用）。这里有一些重构方法也许能够用到，但须要根据实际状况权衡。

可读性强的代码，是咱们的终级目标 —— 谨记，谨记。若是使用递归后会形成代码难以阅读/理解，那就 不要使用递归；换个容易理解的方法吧。

更换堆栈

对递归来讲，最主要的问题是它的内存使用状况。保持堆栈帧跟踪函数调用的状态，并将其分派给下一个递归调用迭。若是咱们弄清楚了如何从新排列咱们的递归，就能够用 PTC 实现递归，并利用 JS 引擎对尾调用的优化处理，那么咱们就不用在内存中保留当前的堆栈帧了。

来回顾下以前用到的一个求和的例子：

function sum(num1,...nums) {
	if (nums.length == 0) return num1;
	return num1 + sum( ...nums );
}
复制代码

这个例子并不符合 PTC 规范。sum(...nums) 运行结束以后，num1 与 sum(...nums) 的运行结果进行了累加。这样的话，当其他参数 ...nums 再次进行递归调用时候，为了获得其与 num1 累加的结果，必需要保留上一次递归调用的堆栈帧。

重构策略的关键点在于，咱们能够经过把 置后 处理累加改成 提早 处理，来消除对堆栈的依赖，而后将该部分结果做为参数传递到递归调用。换句话说，咱们不用在当前运用函数的堆栈帧中保留 num1 + sum(...num1) 的总和，而是把它传递到下一个递归的堆栈帧中，这样就能释放当前递归的堆栈帧。

开始以前，咱们作些改动：把部分结果做为一个新的第一个参数传入到函数 sum(..)：

function sum(result,num1,...nums) {
	// ..
}
复制代码

此次咱们先把 result 和 num1 提早计算，而后把 result 做为参数一块儿传入：

"use strict";

function sum(result,num1,...nums) {
	result = result + num1;
	if (nums.length == 0) return result;
	return sum( result, ...nums );
}
复制代码

如今 sum(..) 已经符合 PTC 优化规范了！耶！

可是还有一个缺点，咱们修改了函数的参数传递形式后，用法就跟之前不同了。调用者不得不在须要求和的那些参数的前面，再传递一个 0 做为第一个参数。

sum( /*initialResult=*/0, 3, 1, 17, 94, 8 );		// 123
复制代码

这就尴尬了。

一般，你们的处理方式是，把这个尴尬的递归函数从新命名，而后定义一个接口函数把问题隐藏起来：

"use strict";

function sumRec(result,num1,...nums) {
	result = result + num1;
	if (nums.length == 0) return result;
	return sumRec( result, ...nums );
}

function sum(...nums) {
	return sumRec( /*initialResult=*/0, ...nums );
}

sum( 3, 1, 17, 94, 8 );								// 123
复制代码

状况好了些。但依然有问题：以前只须要一个函数就能解决的事，如今咱们用了两个。有时候你会发现，在处理这类问题上，有些开发者用内部函数把递归 “藏了起来”：

"use strict";

function sum(...nums) {
	return sumRec( /*initialResult=*/0, ...nums );

	function sumRec(result,num1,...nums) {
		result = result + num1;
		if (nums.length == 0) return result;
		return sumRec( result, ...nums );
	}
}

sum( 3, 1, 17, 94, 8 );								// 123
复制代码

这个方法的缺点是，每次调用外部函数 sum(..)，咱们都得从新建立内部函数 sumRec(..)。咱们能够把他们平级放置在当即执行的函数中，只暴露出咱们想要的那个的函数：

"use strict";

var sum = (function IIFE(){

	return function sum(...nums) {
		return sumRec( /*initialResult=*/0, ...nums );
	}

	function sumRec(result,num1,...nums) {
		result = result + num1;
		if (nums.length == 0) return result;
		return sumRec( result, ...nums );
	}

})();

sum( 3, 1, 17, 94, 8 );								// 123
复制代码

好啦，如今即符合了 PTC 规范，又保证了 sum(..) 参数的整洁性，调用者不须要了解函数的内部实现细节。完美！

但是...天呐，原本是简单的递归函数，如今却出现了不少噪点。可读性已经明显下降。至少说，这是不成功的。有些时候，这只是咱们能作的最好的。

幸运的事，在一些其它的例子中，好比上一个例子，有一个比较好的方式。一块儿从新看下：

"use strict";

function sum(result,num1,...nums) {
	result = result + num1;
	if (nums.length == 0) return result;
	return sum( result, ...nums );
}

sum( /*initialResult=*/0, 3, 1, 17, 94, 8 );		// 123
复制代码

也许你会注意到，result 就像 num1 同样，也就是说，咱们能够把列表中的第一个数字做为咱们的运行总和；这甚至包括了第一次调用的状况。咱们须要的是从新命名这些参数，使函数清晰可读：

"use strict";

function sum(num1,num2,...nums) {
	num1 = num1 + num2;
	if (nums.length == 0) return num1;
	return sum( num1, ...nums );
}

sum( 3, 1, 17, 94, 8 );								// 123
复制代码

帅呆了。比以前好了不少，嗯？！我认为这种模式在声明/合理和执行之间达到了很好的平衡。

让咱们试着重构下前面的 maxEven(..)（目前还不符合 PTC 规范）。就像以前咱们把参数的和做为第一个参数同样，咱们能够依次减小列表中的数字，同时一直把遇到的最大偶数做为第一个参数。

为了清楚起见，咱们可能使用算法策略（相似于咱们以前讨论过的）：

1. 首先对前两个参数 num1 和 num2 进行对比。
2. 若是 num1 是偶数，而且 num1 大于 num2，num1 保持不变。
3. 若是 num2 是偶数，把 num2 赋值给 num1。
4. 不然的话，num1 等于 undefined。
5. 若是除了这两个参数以外，还存在其它参数 nums，把它们与 num1 进行递归对比。
6. 最后，无论是什么值，只需返回 num1。

依照上面的步骤，代码以下：

"use strict";

function maxEven(num1,num2,...nums) {
	num1 =
		(num1 % 2 == 0 && !(maxEven( num2 ) > num1)) ?
			num1 :
			(num2 % 2 == 0 ? num2 : undefined);

	return nums.length == 0 ?
		num1 :
		maxEven( num1, ...nums )
}
复制代码

注意： 函数第一次调用 maxEven(..) 并非为了 PTC 优化，当它只传递 num2 时，只递归一级就返回了；它只是一个避免重复 ％ 逻辑的技巧。所以，只要该调用是彻底不一样的函数，就不会增长递归堆栈。第二次调用 maxEven(..) 是基于 PTC 优化角度的真正递归调用，所以不会随着递归的进行而形成堆栈的增长。

重申下，此示例仅用于说明将递归转化为符合 PTC 规范以优化堆栈（内存）使用的方法。求最大偶数值的更直接方法多是，先对参数列表中的 nums 过滤，而后冒泡或排序处理。

基于 PTC 重构递归，当然对简单的声明形式有一些影响，但依然有理由去作这样的事。不幸的是，存在一些递归，即便咱们使用了接口函数来扩展，也不会很好，所以，咱们须要有不一样的思路。

后继传递格式 （CPS）

在 JavaScript 中， continuation 一词一般用于表示在某个函数完成后指定须要执行的下一个步骤的回调函数。组织代码，使得每一个函数在其结束时接收另外一个执行函数，被称为后继传递格式（CPS）。

有些形式的递归，其实是没法按照纯粹的 PTC 规范重构的，特别是相互递归。咱们以前提到过的 fib(..) 函数，以及咱们派生出来的相互递归形式。这两个状况，皆是存在多个递归调用，这些递归调用阻碍了 PTC 内存优化。

可是，你能够执行第一个递归调用，并将后续递归调用包含在后续函数中并传递到第一个调用。尽管这意味着最终须要在堆栈中执行更多的函数，但因为后继函数所包含的都是 PTC 形式的，因此堆栈内存的使用状况不会无限增加。

把 fib(..) 作以下修改：

"use strict";

function fib(n,cont = identity) {
	if (n <= 1) return cont( n );
	return fib(
		n - 2,
		n2 => fib(
			n - 1,
			n1 => cont( n2 + n1 )
		)
	);
}
复制代码

仔细看下都作了哪些事情。首先，咱们默认用了第三章中的 cont(..) 后继函数表示 identity(..)；记住，它只简单的返回传递给它的任何东西。

更重要的是，这里面增长了不只仅是一个而是两个后续函数。第一个后续函数接收 fib(n-2) 的运行结果做为参数 n2。第二个内部后续函数接收 fib(n-1)的运行结果做为参数 n1。当获得 n1 和 n2 的值后，二者再相加 （n2 + n1），相加的运行结果会传入到下一个后续函数 cont(..)。

也许这将有助于咱们梳理下流程：就像咱们以前讨论的，在递归堆栈以后，当咱们传递部分结果而不是返回它们时，每一步都被包含在一个后续函数中，这拖慢了计算速度。这个技巧容许咱们执行多个符合 PTC 规范的步骤。

在静态语言中，CPS一般为尾调用提供了编译器能够自动识别并从新排列递归代码以利用的机会。很惋惜，不能用在原生 JS 上。

在 JavaScript 中，你得本身书写出符合 CPS 格式的代码。这并非明智的作法；以命令符号声明的形式确定会让内容有些不清楚。 但总的来讲，这种形式仍然要比 for 循环更具备声明性。

警告： 咱们须要注意的一个比较重要的事项是，在 CPS 中，建立额外的内部后续函数仍然消耗内存，但有些不一样。并非以前的堆栈帧累积，闭包只是消耗多余的内存空间（通常状况下，是堆栈里面的多余内存空间）。在这些状况下，引擎彷佛没有启动 RangeError 限制，但这并不意味着你的内存使用量是按比例固定好的。

弹簧床

除了 CPS 后续传递格式以外，另一种内存优化的技术称为弹簧床。在弹簧床格式的代码中，一样的建立了相似 CPS 的后续函数，不一样的是，它们没有被传递，而是被简单的返回了。

再也不是函数调用另外的函数，堆栈的深度也不会大于一层，由于每一个函数只会返回下一个将调用的函数。循环只是继续运行每一个返回的函数，直到再也没有函数可运行。

弹簧床的优势之一是在非 PTC 环境下你同样能够应用此技术。另外一个优势是每一个函数都是正常调用，而不是 PTC 优化，因此它能够运行得更快。

一块儿来试下 trampoline(..)：

function trampoline(fn) {
	return function trampolined(...args) {
		var result = fn( ...args );

		while (typeof result == "function") {
			result = result();
		}

		return result;
	};
}
复制代码

当返回一个函数时，循环继续，执行该函数并返回其运行结果，而后检查返回结果的类型。一旦返回的结果类型不是函数，弹簧床就认为函数调用完成了并返回结果值。

因此咱们可能须要使用前面讲到的，将部分结果做为参数传递的技巧。如下是咱们在以前的数组求和中使用此技巧的示例：

var sum = trampoline(
	function sum(num1,num2,...nums) {
		num1 = num1 + num2;
		if (nums.length == 0) return num1;
		return () => sum( num1, ...nums );
	}
);

var xs = [];
for (let i=0; i<20000; i++) {
	xs.push( i );
}

sum( ...xs );					// 199990000
复制代码

缺点是你须要将递归函数包裹在执行弹簧床功能的函数中; 此外，就像 CPS 同样，须要为每一个后续函数建立闭包。然而，与 CPS 不同的地方是，每一个返回的后续数数，运行并当即完成，因此，当调用堆栈的深度用尽时，引擎中不会累积愈来愈多的闭包。

除了执行和记忆性能以外，弹簧床技术优于CPS的优势是它们在声明递归形式上的侵入性更小，因为你没必要为了接收后续函数的参数而更改函数参数，因此除了执行和内存性能以外，弹簧床技术优于 CPS 的地方还有，它们在声明递归形式上侵入性更小。虽然弹簧床技术并非理想的，但它们能够有效地在命令循环代码和声明性递归之间达到平衡。

总结

递归，是指函数递归调用自身。呃，这就是递归的定义。明白了吧！？

直递归是指对自身至少调用一次，直到知足基本条件才能中止调用。多重递归（像二分递归）是指对自身进行屡次调用。相互递归是当两个或以上函数循环递归 相互 调用。而递归的优势是它更具声明性，所以一般更易于阅读。

递归的优势是它更具声明性，所以一般更易于阅读。缺点一般是性能方面，可是相比执行速度，更多的限制在于内存方面。

尾调用是经过减小或释放堆栈帧来节约内存空间。要在 JavaScript 中实现尾调用 “优化”，须要基于严格模式和适当的尾调用（ PTC ）。咱们也能够混合几种技术来将非 PTC 递归函数重构为 PTC 格式，或者至少能经过平铺堆栈来节约内存空间。

谨记：递归应该使代码更容易读懂。若是你误用或滥用递归，代码的可读性将会比命令形式更糟。千万不要这样作。

** 【上一章】翻译连载 | 第 9 章：递归（上）－《JavaScript轻量级函数式编程》 |《你不知道的JS》姊妹篇 **

iKcamp原创新书《移动Web前端高效开发实战》已在亚马逊、京东、当当开售。

沪江Web前端上海团队招聘【Web前端架构师】，有意者简历至：zhouyao@hujiang.com

iKcamp官网：www.ikcamp.com

---

2019年，iKcamp原创新书《Koa与Node.js开发实战》已在京东、天猫、亚马逊、当当开售啦！