原文地點：
https://github.com/HolyZheng/…

尾調優化

在曉得尾遞歸之前，我們要直到什麼是尾挪用優化，由於尾挪用優化是尾遞歸的基本。尾挪用就是：在函數的末了一步挪用另一個函數。

function f() {
  return g()
}

ps：末了一步必需是之久挪用另一函數，而不能是一個常量或是一個表達式，如 return y 或 return g() + 1

尾挪用優化的道理是什麼？

根據阮一峰先生在es6的函數擴大中的詮釋就是：函數挪用會在內存構成一個“挪用紀錄”，又稱“挪用幀”（call frame），保存挪用位置和內部變量等信息。假如在函數A的內部挪用函數B，那末在A的挪用幀上方，還會構成一個B的挪用幀。比及B運轉完畢，將結果返回到A，B的挪用幀才會消逝。假如函數B內部還挪用函數C，那就另有一個C的挪用幀，以此類推。一切的挪用幀，就構成一個“挪用棧”（call stack）。

這裏的“挪用幀”和“挪用棧”，說的應當就是“實行環境”和“作用域鏈”。由於尾挪用時函數的末了一部操縱，所以不再須要保存外層的挪用幀，而是直接庖代外層的挪用幀，所以能夠起到一個優化的作用。

尾遞歸優化

我們曉得，遞歸雖然運用起來輕易，然則遞歸是在函數內部挪用本身，當遞歸次數到達肯定數量級的時刻，他構成的挪用棧的深度是很恐怖的，極可能會發作“棧溢出”毛病。尾遞歸優化，就是應用尾挪用優化的道理，對遞歸舉行優化。舉一個很罕見的例子：
求斐波那契數值

function fibonacci (n) {
    return n <= 1 ? 1 : fibonacci(n - 1) + fibonacci(n - 2);
}

此函數沒有舉行任何的優化，當我們在掌握台去實行此函數的時刻，fibonacci(40)就已湧現了顯著的相應慢的題目，fibonacci(50)的時刻瀏覽器卡死。
優化

function fibonacci (n, ac1, ac2) {
    (ac1 = ac1 || 1), (ac2 = ac2 || 1);
    return n <= 1 ? ac2 :fibonacci(n - 1, ac2, ac1 + ac2);
}

此優化有兩個點：起首舉行了算法上的優化，減少了許多反覆的盤算，時候複雜度大大下降；第二舉行了尾遞歸優化，按理說不會發作“棧溢出”。我們能夠到掌握台中再嘗試，發明速率的提拔不是平常的快，證實第一個優化見效了，然則當我們許可fibonacci(10000)的時刻，報錯了：Uncaught RangeError: Maximum call stack size exceeded，這就申明我們的尾遞歸優化並沒有見效。為何呢？

局限性

上面說到，我們直接再瀏覽器的掌握台中實行fibonacci(10000)的時刻，發作了棧溢出，這是為何呢？關於這一點，我現在查閱材料以後的明白就是，雖然es6已提出了要完成尾遞歸優化，然則真正落地完成了尾遞歸優化的瀏覽器並不多。所以當我們運用尾遞歸舉行優化的時刻，照舊發作了“棧溢出”的毛病。

蹦床函數

那怎麼辦呢？我們另有另一個要領去到達尾遞歸優化的結果，那就是運用蹦床函數(trampoline)。

function trampoline(f) {
  while (f && f instanceof Function) {
    f = f();
  }
  return f;
}

代碼修改成返回一個新函數。

function fibonacci (n, ac1, ac2) {
    (ac1 = ac1 || 1), (ac2 = ac2 || 1);
    return n <= 1 ? ac2 :fibonacci.bind(null, n - 1, ac2, ac1 + ac2);
}

兩個函數連繫就能夠將遞歸狀況為輪迴，棧溢出的題目也就處理了。

trampoline(fibonacci (100000))
// Infinity