我这里先不说和C之间的性能差距，而是展开说JavaScript递归优化问题，有人问我为什么不说性能差距，我：？？？这个问题就跟问地球为什么是圆的一样(明摆着)
传统的递归函数，比如:
function a(){
return a()
}
这是一个经典的递归，在函数a内部调用自身，调用栈的机制如下:每调用一个函数，解释器就会把该函数添加进调用栈并开始执行.
正在调用栈中执行的函数还调用了其它函数，那么新函数也将会被添加进调用栈，一旦这个函数被调用，便会立即执行.
当前函数执行完毕后，解释器将其清出调用栈，继续执行当前执行环境下的剩余的代码.
当分配的调用栈空间被占满时，会引发“堆栈溢出”错误.
这里我们做一个测试，尝试运行这个递归函数，找出调用栈深度:
let index = 0
function a(){
index += 1
console.log(index)
return a()
}
执行结果如下:
// 省略多行输出
> 12559
> 12560
> 12561
> 12562
> 12563
> Uncaught RangeError: Maximum call stack size exceeded
at console.X.t. [as log] (init.js:1)
这里可以看出，当递归深度达到12563的时候，调用栈爆掉了，平时使用是没有问题的，但是对于某些特殊或者极端情况，你又有相似需求的情况下，怎么样突破这个调用栈限制，做到永不爆栈呢？这里需要一个比较hack的写法, 我们对上面的递归函数进行一下改造:
let index = 0
async function a(){
await undefined
index += 1
console.log(index)
return await a()
}
我们来执行一下看一下结果:
// 省略多行输出
> 100590
> 100591
> 100592
// 省略多行输出
事实上，这个递归函数永远不会停止，它会一直执行下去，也没有爆栈，这是一个神奇的优化，可以让你写出非常大深度的递归而不会出现问题，这个优化的关键就是:
async function() { await undefined }
首先将递归函数改为async函数，然后在内部最好第一行 await undefined；
这个操作的原理就是：
1， async创建微任务队列，然后执行器执行当前队列.
2，此时遇到await undefined，其实这个写法等同于await (async () => {})和await Promise.resolve(setTimeout)这几种写法效果等同，用unedfined只是为了在实现同样效果的情况下更简洁，既然已经等同了，那就从这三个写法分析起.
3，此时，执行器发现第一个任务完全没有等待，马上完成了，但是执行器发现后面的任务是需要等待的，并不会马上完成.
4，这时候执行器为了microtask(也就是协程)调度的合理优化，不会让这个微任务队列始终占有这个execution，而是会把当前微任务队列转移到别的execution去执行(您几位走得慢，请去那边空闲的地方走).
5，转移execution带来的操作就是，因为没办法直接转移调用栈，所以会先将当前调用栈入堆，然后把任务队列转移到别的execution.
6，然后队列里面接下来的任务全部都是使用新创建的execution去执行.
这个操作的本意就是为了让当前栈入堆，而且这个写法在C#和Kotlin里面是完全通用的，因为这3个语言的异步方案都是基本类似，而这个写法来自Rust群一位群友的发现，当时我看到这种写法的时候也表示了惊奇，然后对于递归大面积使用这种写法，目前没有发现什么问题.
这两天发现有人@星风雪月对执行机制有很深的成见，所以我这里使用Node.JS的async hooks做了一下异步执行的调试，这是测试代码:
const async_hooks = require("async_hooks")
let index = 0
let print_buffer = ""
/*** async hooks会追踪async调用,* 而console.log使用异步输出,* 所以这里使用同步方法模拟console*/
function println(log) {
print_buffer += log + "\n"
}
/* 创建钩子 */
async_hooks.createHook({
init(asyncId, type, triggerAsyncId) {
const eid = async_hooks.executionAsyncId()
println("init: *********************************")
println("init: triggerAsyncId " + triggerAsyncId)
println("init: executionAsyncId " + eid)
println("init: asyncId " + asyncId)
println("init: type " + type)
}
})
.enable()
/*********** 测试区 **********/
async function A() {
/* 为了观察方便只执行2次 */
println("A: runing")
index += 1
if (index === 2) return undefined
// 有优化递归 await undefined
return await A()
}
/*********** 测试区 **********/
A().then(() => {
console.log(print_buffer)
})
执行之后的输出:
init: *********************************
init: triggerAsyncId 1
init: executionAsyncId 1
init: asyncId 2
init: type PROMISE
A: runing
init: *********************************
init: triggerAsyncId 2
init: executionAsyncId 1
init: asyncId 3
init: type PROMISE
init: *********************************
init: triggerAsyncId 3
init: executionAsyncId 1
init: asyncId 4
init: type PROMISE
init: *********************************
init: triggerAsyncId 2
init: executionAsyncId 1
init: asyncId 5
init: type PROMISE
init: *********************************
init: triggerAsyncId 4
init: executionAsyncId 4
init: asyncId 6
init: type PROMISE
A: runing
init: *********************************
init: triggerAsyncId 6
init: executionAsyncId 4
init: asyncId 7
init: type PROMISE
这里看executionAsyncId标志，这个是当前执行器的ID，这里可以看到当经过await undefined之后, 执行器从1变成了4，说明这里发生了execution转移，下面我修改一下代码，变成不优化的写法:
// 无优化递归// await undefinedreturn await A()
我这里将await undefined删除，再来执行看看会是什么情况:
init: *********************************
init: triggerAsyncId 1
init: executionAsyncId 1
init: asyncId 2
init: type PROMISE
A: runing
init: *********************************
init: triggerAsyncId 1
init: executionAsyncId 1
init: asyncId 3
init: type PROMISE
A: runing
init: *********************************
init: triggerAsyncId 3
init: executionAsyncId 1
init: asyncId 4
init: type PROMISE
init: *********************************
init: triggerAsyncId 2
init: executionAsyncId 1
init: asyncId 5
init: type PROMISE
再看executionAsyncId，这里始终是使用1去执行，所以没有转移execution执行，这里就很能说明问题了，await undefined可以转移执行器执行，让当前栈入堆，这样可以使调用栈不会溢出，达到深递归优化的目的.
对于评论区朋友说明，这种方式会阻塞macrotask，所以不推荐这种写法，我这里并不表示完全反对意见，我这里来说一下我自己的看法：
异步任务归属microtask，而其他事件回调归属macrotask，microtask的优先级本身就比macrotask要高，所以肯定是microtask先执行，然后才轮到macrotask，像setTimeout(0)这种本身就是属于macrotask，肯定要等到microtask执行完成之后才能执行，不过这确实会带来一个问题，就是对已经运行的macrotask产生时间分辨率精度影响，比如定时器偏移，定时器不会精准得按时间分片执行任务，所以这种写法见仁见智，你如果需要精确macrotask执行的场景还是慎用.
...)
