一千個讀者，有一千個哈姆雷特。
我將會從函式的執行機制、魯棒性、函數語言程式設計、設計模式等方面，全面闡述如何編寫高質量的函式。
引言
如何編寫高質量的函式，這是一個很難回答的問題，不同人心中對高質量有自己的看法，這裡我將全面的闡述我個人對如何編寫高質量函式的一些看法。看法可能不夠全面，也可能會有一些錯誤的見解，歡迎一起討論，就像過日子的人，小吵小鬧總會不經意的出現，一顆包容的心莫過於是最好的 best practice 。
本文寫作風格
寫部落格趨向意識流(胡謅流)，按著我心裡想的去寫，不會去詳細的說明某一個知識點，如果需要詳細討論，可以在文末加我微信細聊。
下面開始吧，我打算用三篇文章來完成 如何編寫高質量的函式 這個系列。
三篇文章我將從以下幾個方面去闡述，如何編寫高質量的函式。
- 函式(一切皆有可能)
- 函式的命名
- 函式的註釋
- 函式的複雜度
- 函式的魯棒性(防禦性程式設計)
- 函式的入參和出參(返回)
- 如何用函數語言程式設計打通函式的任督二脈
- 如何用設計模式讓函式如虎添翼
- 編寫對
V8友好的函式是一種什麼style - 前端工程師的函式狂想錄
下面開始胡謅啦：小聲 BB ，可以先點個贊鼓勵一下麼(給一波精神上的鼓勵)。
PS: 寫過文章的小夥伴都知道，寫一篇好文很不容易，很消耗精力，而寫完部落格後，最大的精神滿足莫過於小夥伴的一個肯定的贊。 哎，其實這個系列已經寫好了，本來想一篇文章發完的，但是看了下，
2萬字，太多了，還是分三篇吧。
本篇只說第一節 函式 ，擒賊先擒王，下面我們來盤一盤函式的七七八八，往 XXX 上盤?。
函式(一切皆有可能)
函式二字，代表著一切皆有可能。
我們想一下：我們用的函式究竟離我們有多遠。就像打麻將一樣，你覺得你能像雀神那樣，想摸啥就來啥麼(誇張修辭手法)。
天天和函式打交道，有沒有想過函式出現的目的是什麼？我們再深入想一下，函式的執行機制是什麼？下面我們就來簡單的分析一下。
函式出現的目的
函式是迄今為止發明出來的用於節約空間和提高效能的最重要的手段。
PS: 注意，沒有之一。
函式的執行機制
有句話說的好，知己知彼，百戰不殆。想要勝利，一定要非常的瞭解敵人。JS 肯定不是敵人啦，但是要想掌握 JS 的函式，要更輕鬆的編寫高質量的函式，那就要去掌握在 JS 中，函式的執行機制。
怎麼去解釋函式的執行機制呢？
我個人認為，很多前端或者其他程式語言的開發者，對計算機的一些底層原理不太清楚，比如編譯原理，計算機組成原理等。
我來模仿一個前端面試題：輸入一個 url 後，會發生什麼？(哈哈哈哈哈隔)。來出一個面試題：
執行一個函式，會發生什麼？
參考下面程式碼:
function say() {
let str = 'hello world'
console.log(str)
}
複製程式碼是不是發現很酷，這道面試題要是交給你，你能答出多少呢？
中斷
5分鐘想一下。
好了，中斷結束。如果讓我來答，我大致會這樣說：
首先我要建立一個函式，打住。如果你學過 C++ ，你可能不會這樣說，你會這樣說，我要先開闢一個堆記憶體。
所以，我會從建立函式到執行函式以及其底層實現，這三個層次進行分析：
建立函式
函式不是平白無故產生的，你要去建立一個函式，而建立函式的時候，究竟發生了什麼呢？
答案如下：
第一步：我要開闢一個新的堆記憶體
為什麼呢？因為每個字母都是要儲存空間的，只要有資料，就一定得有儲存資料的地方。而計算機組成原理中，堆允許程式在執行時動態地申請某個大小的記憶體空間，所以你可以在程式執行的時候，為函式申請記憶體。
第二步：我建立一個函式
say，把這個函式體中的程式碼放在這個堆記憶體中。
想一下函式體是以什麼樣的形式放在堆記憶體中的？很明顯，是以字串的形式。
為什麼呢？我們來看一下 say 函式體的程式碼是什麼，如下：
let str = 'hello world'
console.log(str)
複製程式碼你覺得這些語句以什麼形式的結構放在堆記憶體中比較好呢，不用考慮也是字串，因為沒有規律。如果是物件的話，由於有規律，可以按照鍵值對的形式儲存在堆記憶體中。而沒規律的通常都是變成字串的形式。
第三步：在當前上下文中宣告
say函式(變數)，函式宣告和定義會提升到最前面
注意有個關鍵的點，就是當前上下文，我們可以理解為上下文堆疊(棧)，say 是放在堆疊(棧)中的，同時它的右邊還有一個堆記憶體地址，用來指向堆中的函式體的。
PS: 建議去學習一下資料結構，棧中的一塊一塊的，我們稱為幀。你可以把棧理解中 DOM 樹，幀理解為節點，每一幀( 節點 )都有自己的名字和內容。
第四步：把開闢的堆記憶體地址賦值給函式名
say
這裡一個關鍵點就是，把堆記憶體地址賦值給函式名 say。
我特意在白板上畫了一個簡單的示意圖：
結合上圖 say 右邊的儲存，再去理解上面的四個步驟，是不是有點感悟了呢。
你真的懂賦值這個操作嗎？
這裡我突然想提一個簡單的知識，就是賦值這個操作，比如我把堆記憶體地址賦值給函式名 say ，那麼這意味著什麼呢？
有很多人可能不明白，其實這裡很簡單，這一步賦值操作，從計算機組成原理角度看，記憶體分為好幾個區域，比如程式碼區域，棧區域，堆區域等。
理解這幾個區域一個最關鍵的點，就是要明白，每一個儲存空間的記憶體地址都是不一樣。也就是說，賦值(引用型別)的操作就是將堆區域的某一個地址，通過匯流排管道流入(複製)到對應棧區域的某一個地址中，從而使棧區域的某一個地址內的儲存空間中有了引用堆區域資料的地址，這裡業界叫控制程式碼，說白了就是指標。只不過在高階語言中，把指標給隱藏了，直接有變數代替指標。
所以一個簡單的賦值，其在計算機底層實現上，都是很複雜的，這裡，也許通過組合語言，你可以更好的去理解賦值的真正含義，比如 1 + 1 用匯編語言編寫，就是下面程式碼：
start：
mov ax, 1
mov bx, 1
add ax, bx
end start;
複製程式碼從上面程式碼中，我們可以看到，把 1 賦值給 ax ，使用到了 mov 指令。而 mov 是 move 移動的縮寫，這也證明了，在賦值這個操作上，其實本質上是資料或者資料的控制程式碼在一張地址表中的流動。
PS: 所以如果是值型別，那就是直接把資料，流(移動)到指定記憶體地址的儲存空間中。
建立函式就先說到這了，其實我已經說得非常詳細了，從計算機底層去解釋一些最基礎的現象。
執行函式
執行函式這個步驟，也非常重要，執行函式究竟是什麼樣的過程，現在我就用我個人的總結去解釋這個過程。
思考一個點。
我們知道，函式體的程式碼是在儲存在堆記憶體中的，而且是字串形式。那麼如果我們要執行堆記憶體中的程式碼，首先要做的就是講字串變成真正的 JS 程式碼，這個是比較容易理解的，就像資料傳輸中的序列化和反序列化。
思考題一：為什麼會存在序列化和反序列化？大家可以自行思考一下，有些越簡單的道理，背後越是有著非凡的思想
將字串變成真正的 JS 程式碼
如何將字串變成 JS 程式碼，這裡有一個前置知識，就是：
每一個函式呼叫，都會在函式上下文堆疊中建立幀。
棧是什麼？
棧是一個基本的資料結構，這裡我就不解釋了，小夥伴不懂的先去百度一下看看。
為什麼函式執行要在棧中執行呢？
最關鍵的一點就是，棧是先進後出的資料結構，我們想一下，被也就意味著可以很好的儲存和恢復呼叫現場。為什麼？我們來看一段程式碼：
function f1() {
let b = 1;
function f2() {
cnsole.log(b)
}
return f2
}
let fun = f1()
fun()
複製程式碼這裡先不解釋，繼續往下看。
函式上下文堆疊是什麼？
我們可以這樣去理解，函式上下文堆疊是一個資料結構，不管它是什麼，如果學過 C++ 或者 C 的，可以理解成是一個 struct (結構體)。這個結構體負責管理函式執行已經關閉變數作用域。函式上下文堆疊在程式執行時就會產生，並且一開始加入到棧裡面的是全域性上下文幀，位於棧底。
開始執行函式
首先要明白一點：
執行函式(函式呼叫)是在棧上完成的 。
這也就是為什麼 JS 函式可以遞迴。因為棧的先進後出的資料結構，賦予了其遞迴能力。
繼續往下看，函式執行大致有以下步驟：
第一步：會形成一個供程式碼執行的環境，也是一個棧記憶體
這裡，我們先思考幾個問題：
- 這個供程式碼執行的環境是什麼？
- 這個棧記憶體是怎麼分配出來的？
- 這個棧記憶體的內部是一種什麼樣的樣子？
第二步：將儲存的字串複製一份到新開闢的棧記憶體中，使其變為真正的
JS程式碼
這步很好理解，
第三步：先對形參進行賦值，再進行變數提升，比如將
varfunction變數提升。
第四步：在這個新開闢的作用域中自上而下執行
思考題：為什麼是自上而下執行呢？
將執行結果返回給當前呼叫的函式
思考題：將執行結果返回給當前呼叫的函式，其背後是如何實現的呢？
談談底層實現
這裡為什麼要談談底層實現呢，因為有還有一些知識點我沒有提到，比如前面的一些思考，這裡我想統一提一下。
計算機中最本質的閉包解釋
函式在執行的時候，都會形成一個全新的私有作用域，也叫私有棧記憶體。
目的有如下幾點：
第一點：把原有堆記憶體中儲存的字串變成真正的 JS 程式碼
第二點： 保護該棧記憶體的私有變數不受外界的干擾
函式執行的這種保護機制，在計算機中稱之為 閉包 。
可能有人不明白，咋就私有了呢？
沒問題，我們可以反推。假設不是私有棧記憶體的，那麼當你執行一個遞迴時，基本就完了，因為一個函式上下文堆疊中，有很多相同的 JS 程式碼，比如區域性變數等，如果不私有化，那豈不亂套了，所以假設矛盾，私有棧記憶體成立。
棧記憶體是怎麼分配出來？
首先，你要明白 JS 的棧記憶體是系統自動分配的，大小固定。想一想，如果自動適應的話，那就基本不存在除死迴圈這種情況之外的的棧溢位了。
這個棧記憶體的內部是一種什麼樣的樣子？
這個確實挺讓人好奇的，為什麼呢？我舉個例子，你天天寫 return 語句，那你知道 return 的底層實現嗎？你天天都在寫子程式，那你知道子程式的底層的一些真相嗎？
我們來看一張圖：
上圖顯示了一次函式呼叫的棧結構，從結構中我們可以看到，內部有哪些東西，比如實參，區域性變數，返回地址。
看下面程式碼：
function f1() {
return 'hello godkun'
}
let result = f1()
f2(result)
複製程式碼上面這行程式碼的底層含義就是，f() 函式在私有棧記憶體中執行完後，使用 return 後，將 return 後的執行結果傳遞給 EAX (累加暫存器)，常用於函式返回值。對暫存器不瞭解的可以自行搜尋學習一下，這裡就不再說了。這裡我說一下 Return Addr ，Addr 主要目的是讓子程式能夠多次被呼叫。
看下面程式碼：
function main() {
say()
// TODO:
say()
}
複製程式碼上面程式碼，在 main 函式中進行了多次呼叫子程式 say ，在底層實現上面，是通過在棧結構中儲存一個 Addr 用來儲存函式的起始執行地址，當第一個 say 函式執行完以後，Addr 就會指向起始執行地址，以備後面多次呼叫子程式。
JS 引擎是如何執行函式
上面我從很多方面分析了函式執行的機制，可能有點難懂。現在我來簡要分析一下，JS 引擎是如何執行函式的。
這裡我就不造輪子了，有一篇部落格寫的非常好，我發自內心的認為我寫不出來比這還好的部落格了。就算寫出來，我感覺也沒必要了。但是這篇部落格寫的過於概括，很多細節沒有提到，這裡我要在此篇部落格的基礎上分析很多很重要的細節。
部落格地址：
下面我開始分析，程式碼如下：
//定義一個全域性變數 x
var x = 1
function A(y) {
//定義一個區域性變數 x
var x = 2
function B(z) {
//定義一個內部函式 B
console.log(x + y + z)
}
//返回函式B的引用
return B
}
//執行A,返回B
var C = A(1)
//執行函式B
C(1)
複製程式碼PS: 建議大家先看一下部落格，知道一些基本概念，然後再看我的分析。
下面開始分析：
執行
A函式時
JS 引擎構造的 ESCstack 結構如下：
簡稱 A 圖：
執行
B函式時
JS 引擎構造的 ESCstack 結構如下：
簡稱 B 圖:
下面開始最為關鍵的個人感悟 show time 。
區域性變數是如何被儲存起來的
核心看下面程式碼：
EC(B) = {
[scope]:AO(A),
var AO(B) = {
z:1,
arguments:[],
this:window
},
scopeChain:<AO(B),B[[scope]]>
}
複製程式碼這是在執行 B函式 時，建立的 B 函式的執行環境(一個物件結構)。裡面有一個 AO(B) ，這是 B 函式的活動物件。
那AO(B) 的目的是什麼？其實 AO(B) 就是每個連結串列的節點其指向的內容。
同時，這裡還定義了 [scope] 屬性，我們可以理解為指標，[scope] 指向了 AO(A) ，而 AO(A) 就是函式 A 的活動物件。
函式活動物件儲存著 區域性變數、引數陣列、this 屬性。這也是為什麼你可以在函式內部使用 this 和 arguments 的原因。
scopeChain 是作用域鏈，熟悉資料結構的同學肯定知道我想說什麼了，其實函式作用域鏈本質就是連結串列，執行哪個函式，那連結串列就初始化為哪個函式的作用域，然後把當前指向的函式活動物件放到 scopeChain 連結串列的表頭中。
比如執行 B 函式，那 B 的連結串列看起來就是 AO(B) --> AO(A)
但是別忘了，A 函式也是有自己的連結串列的，為 AO(A) --> VO(G)。所以整個連結串列就串起來來，B 的連結串列(作用域)就是：AO(B) --> AO(A) --> VO(G)
連結串列是一個閉環，因為查了一圈，回到自己的時候，如果還沒找到，那就返回 undefined 。
思考題：大家可以思考一下 [scope] 和 [[scope]] 的命名方式，為什麼是這種形式。
通過 A 函式的 ECS 我們能看到什麼
我們能看到，JS 語言是靜態作用域語言，在執行函式之前，整個程式的作用域鏈就一樣確定好了，從 A 圖中的函式 B 的 B[[scope]] 就可以看到作用域鏈已經確定好了。不像 lisp 那種在執行時才能確定作用域。
執行環境，上下文環境是一種什麼樣的存在
執行環境的資料結構是棧結構，其實本質上是給一個陣列增加一些屬性和方法。
執行環境可以用 ECStack 去表示，可以理解成 ECSack = [] 這種形式。
棧(執行環境)專門用來存放各種資料，比如最經典的就是儲存函式執行時的各種子資料結構。
比如 A 函式的執行環境是 EC(A)。當執行函式 A 的時候，相當於 ECStack.push[A] ，當屬於 A 的那些東西被放入到棧中的時候，都會被包裹成一個私有棧記憶體。
私有棧是怎麼形成的，這裡就要牽扯到組合語言了，從組合語言角度去看，會發現一個棧的記憶體分配，棧結構的各種變換，都是有底層標準去控制的。
所以我們再聯絡一下，平常我們所說的上下文環境啊，context 等，其實和我上面解釋的執行環境並沒有什麼區別，這樣去理解，是不是發現對上下文環境之類的專有名詞理解的更為深刻了呢。
因為再跳，本質還是一樣的，計算機行業底層標準是確定的。
開啟上帝模式看穿 this
this為什麼在執行時才能確定
我們看上面兩張圖中的紅色箭頭，箭頭處的資訊非常非常重要。
看 A 圖，執行 A 函式時，只有 A 函式有 this 屬性，執行 B 函式時，只有 B 函式有 this 屬性，這也就證實了 this 只有在執行時才會存在。
this的指向真相
我們看一下 this 的指向，A 函式呼叫的時候，屬性 this 的屬性是 window ，而 通過 var C = A(1) 呼叫 A 函式後，A 函式的執行環境已經 pop 出棧了。此時執行 C() 就是在執行 B 函式，EC(B) 已經在棧頂了，this 屬性值是 window 全域性變數。
通過 A 圖 和 B 圖的比較，直接展示 this 的本質。看清真相，this 也不過如此。
作用域的本質是連結串列中的一個節點。
聽不懂沒關係，聽我娓娓道來。
通過
A圖 和B圖的比較，直接秒殺 作用域 的所有用法
看 A 圖，執行 A 函式時，B 函式的作用域是建立 A 函式的活動物件 AO(A) 。作用域就是一個屬性，一個屬於 A函式的執行環境中的屬性，它的名字叫做 [scope] 。
[scope] 指向的是一個函式活動物件，其實這裡最核心的一點，就是大家要把這個函式物件當成一個作用域，但最好理解成一個連結串列節點。
如果你能理解成連結串列節點的話，那你就不會再對為什麼會有作用域鏈這個東西感到陌生，不會再對作用域和作用域鏈的區別而感到困惑。直接秒殺了作用域相關的所有問題。
PS:
B執行B函式時，只有B函式有this屬性，這也就交叉證實了this只有在執行時才會存在。
作用域鏈的本質就是連結串列
首先通過比較 A 圖和 B 圖的 scopeChain ，我們可以確定的是：
作用域鏈本質就是連結串列，執行哪個函式，那連結串列就初始化為哪個函式的作用域，然後將該函式的 [scope] 放在表頭，形成閉環連結串列，作用域鏈的查詢，就是通過連結串列查詢的，如果走了一圈還沒找到，那就返回 undefined 。
作用域鏈也是很 easy 的。
用一道面試題讓你更上一層樓(走火入魔)
我決定再舉一個例子，這是一個經常被問的面試題，看下面程式碼：
第一個程式如下：
function kun() {
var result = []
for (var i = 0; i < 10; i++) {
result[i] = function() {
return i
}
}
return result
}
let r = kun()
r.forEach(fn => {
console.log('fn',fn())
})
複製程式碼第二個程式如下：
function kun() {
var result = []
for (var i = 0; i < 10; i++) {
result[i] = (function(n) {
return function() {
return n
}
})(i)
}
return result
}
let r = kun()
r.forEach(fn => {
console.log('fn', fn())
})
複製程式碼上面兩個程式會輸出什麼結果？並分析一下其原理。
輸出結果大家應該都知道了，結果分別是如下截圖：
第一個程式，輸出 10 個 10 ：
第二個程式，輸出 0 到 9 ：
那麼問題來了，其內部的原理機制你知道嗎？
- 一部分
coder只能答到立即呼叫，閉包。 - 大多數
coder可以答到作用域相關知識。 - 極少部分
coder(大佬級別) 可以從核心底層原因來分析。
下面我來展示一下從核心底層原因來分析，是一種什麼樣的 style 。
分析輸出10個10
程式碼如下：
function kun() {
var result = []
for (var i = 0; i < 10; i++) {
result[i] = function() {
return i
}
}
return result
}
let r = kun()
r.forEach(fn => {
console.log('fn',fn())
})
複製程式碼如何去分析，首先我們要明白一點，只有函式在執行的時候，函式的執行環境才會生成。那依據這個規則，我們可以知道在完成 r = kun() 的時候，kun 函式只執行了一次，生成了對應的 AO(kun) 。我們可以看一下 AO(kun) 有什麼，如下：
AO(kun):{
i = 10;
kun = function(){...};
kun[[scope]] = this;
}
複製程式碼這時，在執行 kun() 之後，i 的值已經是 10 了。OK ，下面最關鍵的一點要來了，請注意，kun 函式只執行了一次，也就意味著:
在 kun 函式的 AO(kun) 中的 i 屬性是 10 。
我們繼續分析， kun 函式的作用域鏈如下：
AO(kun) --> VO(G)
而且 kun 函式已經從棧頂被刪除了，之只留下了 AO(kun) ，注意一點：
這裡的 AO(kun) 表示一個節點，這個節點有指標和資料，其中指標指向了 VO(G) ，資料就是 kun 函式的活動物件。
所以下面問題來了，當去一次執行 result 中的陣列的時候，會發生什麼現象？注意一點：
result 陣列中的每一個函式其作用域都已經確定了，上面也提到過，JS 是靜態作用域語言，其在程式宣告階段，所有的作用域都將確定。
所以知道這點以後，那麼 result 陣列中每一個函式其作用域鏈都是如下：
AO(result[i]) --> AO(kun) --> VO(G)
複製程式碼因此 result 中的每一個函式執行時，其 i 的值都是沿著這條作用域鏈去查詢的，而且由於 kun 函式只執行了一次，導致了 i 值是最後的結果，也就是 10 。所以輸出結果就是 10 個 10 。
總結一下，就是 result 陣列中的 10 個函式在宣告後，總共擁有了 10 個連結串列(作用域鏈)，都是 AO(result[i]) --> AO(kun) --> VO(G)
這種形式，但是 10 個作用域鏈中的 AO(kun) 都是一樣的。所以導致了，輸出結果是 10 個 10 。
通過上面的解釋，其實已經從一個相當底層的視角去分析了，需要注意的關鍵點，我也都提了出來，大家再好好研究下吧。
下面我們來分析輸出 0 到 9 的結果。
分析輸出0到9
程式碼如下：
function kun() {
var result = []
for (var i = 0; i < 10; i++) {
result[i] = (function(n) {
return function() {
return n
}
})(i)
}
return result
}
let r = kun()
r.forEach(fn => {
console.log('fn', fn())
})
複製程式碼通過分析 輸出結果為 10 個 10 的情況，大家應該有所收穫了，或者找到一些感覺了，那輸出 0 到 9 結果的情況，該怎麼去分析呢？且聽我娓娓道來。
首先和上面不一樣了，在宣告函式 kun 的時候，就已經執行了 10 次匿名函式了。還記得只要執行函式，就會生成函式執行環境麼。也就意味著，在 ECS 棧中，有 10 個 EC(kun) 執行環境，分別對應的是 result 陣列中的 10 個函式。
具體展示情況，我來用虛擬碼表達一下：
ECSack = [
EC(kun) = {
[scope]: VO(G)
AO(kun) = {
i: 0,
result[0] = function() {...// return i},
arguments:[],
this: window
},
scopeChain:<AO(kun), kun[[scope]]>
},
// .....
EC(kun) = [
[scope]: VO(G)
AO(kun) = {
i: 9,
result[9] = function() {...// return i},
arguments:[],
this: window
},
scopeChain:<AO(kun), kun[[scope]]>
]
]
複製程式碼上面簡單的用結構化的語言表示了 kun 函式在宣告時的內部情況，首先有兩點要注意。
第一點：每一個 EC(kun) 中的 AO(kun) 中的 i 屬性值都是不一樣的，比如通過上面結構化表示，可以看到：
result[0]函式的父執行環境是EC(kun)，這個VO(kun)裡面的i值 是0。result[9]函式的父執行環境是EC(kun)，這個VO(kun)裡面的i值 是9。
第二點：關於作用域鏈，也就是 scopeChain ，result 中的函式的 連結串列形式仍然是下面這種形式
AO(result[i]) --> AO(kun) --> VO(G)
複製程式碼但不一樣的是，對應節點的儲存地址不一樣了，相當於是 10 個新的 AO(kun) 。而每一個 AO(kun) 的節點內容中的 i 值是不一樣的。
所以總結下就是：
執行 result 陣列中的 10 個函式時，走了 10 個不同的連結串列，同時每個連結串列的 AO(kun) 節點是不一樣的。每個 AO(kun) 節點中的 i 值也是不一樣的。
所以輸出的結果最後顯示為 0 到 9 。
總結
是不是發現從底層去分析和理解的話，很多問題其實都有一個很合理，或者讓閱讀者可以接受的答案。
總結
敲山震虎篇的知識難度有點大，費了我不少腦子，通過對底層實現原理的分析，我們可以更加深刻的去理解函式的執行機制。
深刻的理解了函式的執行機制，我們才能更流暢的寫出高質量的函式。
如何減少作用域鏈(連結串列)的查詢
比如我們看很多庫，想 JQ 等，都會在立即執行函式的最外面傳一個 window 引數。這樣做的目的是因為，window 是全域性物件，通過傳參，避免了查詢整個作用域鏈。提高了函式的執行效率，見解了寫出了高質量的函式。
如何防止棧溢位 我們知道，每一次執行函式，都會建立函式的執行環境，也就意味著佔用一些棧記憶體，而棧記憶體大小是固定的，如果寫了很大的遞迴函式，你們就會造成棧記憶體溢位，引發錯誤。
我覺得，我們要去努力的達成這樣一個成就：
做到當我在手寫一個函式時，我心中非常清楚的知道我正在寫的每一行程式碼，其在記憶體中是怎麼表現的，或者說其在底層是如何執行的，從而達到 眼中有碼，心中無碼 的境界。
如果能做到這樣的話，那還怕寫不出高質量的函式嗎？
備註
- 敲山震虎篇閱讀難度有點大，多去分析分析就會明白了
- 文章難免有錯，還請多多包涵，歡迎在評論處指出錯誤，多多交流
參考
交流
後續會有其他兩篇部落格，分別是基礎篇和高階篇，可以關注我的掘金部落格或者 github 來獲取後續的系列文章更新通知。
掘金系列技術文章彙總如下，覺得不錯的話，點個 star 鼓勵一下。
我是原始碼終結者，歡迎技術交流。
也可以進 前端狂想錄群 大家一起頭腦風暴。有想加的，因為人滿了，可以先加我好友，我來邀請你進群。
風之語
今天是一個開心的節日，既是吃湯圓猜燈謎的元宵節，也是程式設計師通宵的節日(猿宵節)。
雖然 20 號了，但啥也別說了，祝各位首富來年元宵節快樂(嘿嘿)。
最後：尊重原創，轉載請註明出處哈?