如何編寫高質量的函式 -- 敲山震虎篇
一千個讀者，有一千個哈姆雷特。
我將會從函式的執行機制、魯棒性、函數語言程式設計、設計模式等方面，全面闡述如何編寫高質量的函式。
序
如何編寫高質量的函式，這是一個很難回答的問題，不同人心中對高質量有自己的看法，這裡我將全面的闡述我個人對如何編寫高質量函式的一些看法。看法可能不夠全面，也可能會有一些錯誤的見解，歡迎一起討論，就像過日子的人，小吵小鬧總會不經意的出現，一顆包容的心莫過於是最好的 best practice 。
現實很骨感
有些時候，可愛的你可能會有這樣的疑問，我也知道要編寫高質量的函式，我也知道編寫高質量函式的基本方法，但是我在工作中就是沒法付出實踐，一而再，再而三的沒法付出實踐。
像這種知道怎麼做，但是無法付出實踐的事情，其實不是你個人的問題，這是個通病，幾乎 90% 的人都會遇到，那麼原因是什麼呢？
我個人認為，這需要從兩個層次去理解，為什麼現實很骨感。
接手舊業務
首先，這裡的舊業務是指：你要在別人完成好的某個需求的程式碼基礎上進行開發。這幾乎是所有 coder 都會遇到的情況。每個人可能都會在工作中吐槽一句，這寫的什麼玩意？之類的吐槽話。很正常，說不定你寫的程式碼，此刻也正在被別的 coder 吐槽呢。
為什麼舊業務的現實很骨感，原因大致如下：
200 coding
接手新業務
能接新業務，算是很不錯的了，從業務程式碼的初始化到完成上線，都是你全程參與，既可以鍛鍊你的工程化思想，也可以實踐一下你寫的程式碼在日後能不能輕鬆的擴充套件。少被別的 coder 說坑。
但是就算是在做新業務的情況下，現實有時也很骨感，原因大致如下：
coder 7
總結
上面的是我個人的看法，但是八九不離十。很多情況下，不是不會，努力努力都會的，但是有時候啊，你會發現，總會有一部分人在儘可能的去嘗試，然後你和別人的差距就出來了。可以這麼說，這裡的每一個理由，都可以抽象成一個需求，而你要做的就是去努力解決這個需求。加油吧少年，人與人的差距就是這樣產生的。
幕後花絮：事實是，我的一些業務(不開心的業務等因素)程式碼，也很一般，我同事看到此文別笑，都是搬磚工(碼農)，何苦為難搬磚工(碼農)。
本文寫作風格
上面我又胡謅了一些東西，控制不住，本人一副要準備寫長篇小說的樣子(不要臉)，因為我覺得，我的部落格不能太官方，不然我自己都不想看。寫部落格趨向意識流(胡謅流)，按著我心裡想的去寫，不會去詳細的說明某一個知識點，如果需要詳細討論，可以在文末加我微信細聊，或者掃碼進微信群大家一起頭腦風暴。
微信二維碼如下：
歡迎小夥伴入群一起討論技術，一起進步，群很活躍，技術氛圍不錯。
好了，胡謅完了，下面開始吧，我打算用三篇文章來完成 如何編寫高質量的函式 這個系列。
三篇文章我將從以下幾個方面去闡述，如何編寫高質量的函式。
- 函式(一切皆有可能)
- 函式的命名
- 函式的註釋
- 函式的複雜度
- 函式的魯棒性(防禦性程式設計)
- 函式的入參和出參(返回)
- 如何用函數語言程式設計打通函式的任督二脈
- 如何用設計模式讓函式如虎添翼
- 編寫對
V8友好的函式是一種什麼style - 前端工程師的函式狂想錄
下面開始胡謅啦：小聲 BB ，可以先點個贊鼓勵一下麼(給一波精神上的鼓勵)。
PS: 寫過文章的小夥伴都知道，寫一篇好文很不容易，很消耗精力，而寫完部落格後，最大的精神滿足莫過於小夥伴的一個肯定的贊。 哎，其實這個系列已經寫好了，本來想一篇文章發完的，但是看了下， 2 萬字，太多了，還是分三篇吧。
本篇只說第一節 函式 ，擒賊先擒王，下面我們來盤一盤函式的七七八八，往 XXX 上盤:joy:。
函式(一切皆有可能)
函式二字，代表著一切皆有可能。
我們想一下：我們用的函式究竟離我們有多遠。就像打麻將一樣，你覺得你能像雀神那樣，想摸啥就來啥麼(誇張修辭手法)。
天天和函式打交道，有沒有想過函數出現的目的是什麼？我們再深入想一下，函式的執行機制是什麼？下面我們就來簡單的分析一下。
函數出現的目的
函式是迄今為止發明出來的用於節約空間和提高效能的最重要的手段。
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 程式碼
這步很好理解，
第三步：先對形參進行賦值，再進行變數提升，比如將 var function 變數提升。
第四步：在這個新開闢的作用域中自上而下執行
思考題：為什麼是自上而下執行呢？
將執行結果返回給當前呼叫的函式
思考題：將執行結果返回給當前呼叫的函式，其背後是如何實現的呢？
談談底層實現
這裡為什麼要談談底層實現呢，因為有還有一些知識點我沒有提到，比如前面的一些思考，這裡我想統一提一下。
計算機中最本質的閉包解釋
函式在執行的時候，都會形成一個全新的私有作用域，也叫私有棧記憶體。
目的有如下幾點：
第一點：把原有堆記憶體中儲存的字串變成真正的 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 那種在執行時才能確定作用域。
執行環境是一種什麼樣的存在
其實可以把執行環境是看出是一個物件結構，比如 A 函式的執行環境是 EC(A) 有 [scope] 屬性
開啟上帝模式看穿 this
this 為什麼在執行時才能確定
我們看上面兩張圖中的紅色箭頭，箭頭處的資訊非常非常重要。
看 A 圖，執行 A 函式時，只有 A 函式有 this 屬性，執行 B 函式時，只有 B 函式有 this 屬性，這也就證實了 this 只有在執行時才會存在。
通過 A 圖 和 B 圖的比較，直接展示 this 的本質。看清真相， this 也不過如此。
this 的指向真相
我們看一下 this 的指向， A 函式呼叫的時候，屬性 this 的屬性是 window ，而 通過 var C = A(1) 呼叫 A 函式後， A 函式的執行環境已經 pop 出棧了。此時執行 C() 就是在執行 B 函式， EC(B) 已經在棧頂了， this 屬性值是 window 全域性變數。
作用域
通過 A 圖 和 B 圖的比較，直接秒殺 作用域 的所有用法
看 A 圖，執行 A 函式時， B 函式的作用域是建立 A 函式的活動物件，同時也是 B 執行 B 函式時，只有 B 函式有 this 屬性，這也就證實了 this 只有在執行時才會存在。
我們顯示的看到了函式的作用域是怎麼形成的，也看
通過 A 圖 和 B 圖的比較，直接秒殺 作用域鏈 的知識
首先我們可以確定的是，作用域鏈本質就是連結串列，執行哪個函式，那連結串列就初始化為哪個函式的作用域，然後將。
用一道面試題讓你更上一層樓(走火入魔)
我決定再舉一個例子，這是一個經常被問的面試題，看下面程式碼：
第一個程式如下：
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 函式只執行了一次，生成了對應的 VO(kun) 和 AO(kun) 。我們可以看一下 VO(kun) 有什麼，如下：
VO(G):{
i = 10;
kun = function(){...};
kun[[scope]] = this;
}
複製程式碼
這時，在執行 kun() 之後， i 的值已經是 10 了。 OK ，下面最關鍵的一點要來了，請注意， kun 函式只執行了一次，也就意味著:
在 kun 函式的 scopeChain 也就是連結串列(作用域鏈)裡的 VO(G) 中的 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) 和 VO(G) 都是一樣的。所以導致了，輸出結果是 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) = {
result[0] = function() {...},
arguments:[],
this: window
},
scopeChain:<AO(kun), kun[[scope]]>
},
// .....
EC(kun) = [
[scope]: VO(G)
AO(kun) = {
result[9] = function() {...},
arguments:[],
this: window
},
scopeChain:<AO(kun), kun[[scope]]>
]
]
複製程式碼
上面簡單的用結構化的語言表示了 kun 函式在宣告時的內部情況，首先有兩點要注意。
第一點：每一個 EC(kun) 中的 VO(G) 都是不一樣的，比如通過上面結構化表示，可以看到， result[0] 函式的父執行環境的 [scope] 是 VO(G) ，同時這個 VO(G) 裡面的 i 是 0 。記住 VO(G) 是一段儲存空間，每個 EC(kun) 的 VO 都是不一樣的。
第二點：關於作用域鏈，也就是 scopeChain ， 10 函式，連結串列形式仍然是下面這種形式
AO(result[i]) --> AO(kun) --> VO(G) 複製程式碼
但不一樣的是，對應節點的儲存地址不一樣了，相當於是 10 個新的 AO(kun) 。而每一個 AO(kun) 的節點內容中的 i 值是不一樣的， i 是存的當時立即執行時， VO(G) 中的 i 的值。
所以總結下就是：
執行 result 陣列中的 10 個函式時，走了 10 個不同的連結串列，同時每個連結串列的 AO(kun) 節點是不一樣的。每個 AO(kun) 節點中的 i 值也是不一樣的。
所以輸出的結果最後顯示為 0 到 9 。
總結
是不是發現從底層去分析和理解的話，很多問題其實都有一個很合理，或者讓閱讀者可以接受的答案。
總結
敲山震虎篇的知識難度有點大，費了我不少腦子，通過對底層實現原理的分析，我們可以更加深刻的去理解函式的執行機制。
深刻的理解了函式的執行機制，我們才能更流暢的寫出高質量的函式。
如何減少作用域鏈(連結串列)的查詢
比如我們看很多庫，想 JQ 等，都會在立即執行函式的最外面傳一個 window 引數。這樣做的目的是因為， window 是全域性物件，通過傳參，避免了查詢整個作用域鏈。提高了函式的執行效率，見解了寫出了高質量的函式。
如何防止棧溢位 我們知道，每一次執行函式，都會建立函式的執行環境，也就意味著佔用一些棧記憶體，而棧記憶體大小是固定的，如果寫了很大的遞迴函式，你們就會造成棧記憶體溢位，引發錯誤。
我覺得，我們要去努力的達成這樣一個成就：
做到當我在手寫一個函式時，我心中非常清楚的知道我正在寫的每一行程式碼，其在記憶體中是怎麼表現的，或者說其在底層是如何執行的，從而達到 眼中有碼，心中無碼 的境界。
如果能做到這樣的話，那還怕寫不出高質量的函式嗎？
備註
- 敲山震虎篇閱讀難度有點大，多去分析分析就會明白了
- 文章難免有錯，還請多多包涵，歡迎在評論處指出錯誤，多多交流
參考
交流
後續會有其他兩篇部落格，分別是基礎篇和高階篇，可以關注我的掘金部落格或者 github 來獲取後續的系列文章更新通知。
掘金系列技術文章彙總如下，覺得不錯的話，點個 star 鼓勵一下。
我是原始碼終結者，歡迎技術交流。
風之語
今天是一個開心的節日，既是吃湯圓猜燈謎的元宵節，也是程式設計師通宵的節日(猿宵節)。
雖然 20 號了，但啥也別說了，祝各位首富來年元宵節快樂(嘿嘿)。