壹 ❀ 引
我們都知道，JS代碼的執行順序總是與代碼先后順序有所差異，當先拋開異步問題你會發現就算是同步代碼，它的執行也與你的預期不一致，比如：
function f1() { console.log('聽風是風'); }; f1(); //echo function f1() { console.log('echo'); }; f1(); //echo
按照代碼書寫順序，應該先輸出 聽風是風，再輸出 echo才對，很遺憾，兩次輸出均為 echo；如果我們將上述代碼中的函數聲明改為函數表達式，結果又不太一樣：
var f1 = function () { console.log('聽風是風'); }; f1(); //聽風是風 var f1 = function() { console.log('echo'); }; f1(); //echo
這說明代碼在執行前一定發生了某些微妙的變化，JS引擎究竟做了什么呢？這就不得不提JS執行上下文的了。
貳 ❀ JS執行上下文
JS代碼在執行前，JS引擎總要做一番准備工作，這份工作其實就是創建對應的執行上下文；
執行上下文有且只有三類，全局執行上下文，函數上下文，與eval上下文；由於eval一般不會使用，這里不做討論。
1.全局執行上下文
全局執行上下文只有一個，在客戶端中一般由瀏覽器創建，也就是我們熟知的window對象，我們能通過this直接訪問到它。
全局對象window上預定義了大量的方法和屬性，我們在全局環境的任意處都能直接訪問這些屬性方法，同時window對象還是var聲明的全局變量的載體。我們通過var創建的全局對象，都可以通過window直接訪問。
2.函數執行上下文
函數執行上下文可存在無數個，每當一個函數被調用時都會創建一個函數上下文；需要注意的是，同一個函數被多次調用，都會創建一個新的上下文。
說到這你是否會想，上下文種類不同，而且創建的數量還這么多，它們之間的關系是怎么樣的，又是誰來管理這些上下文呢，這就不得不說說執行上下文棧了。
叄 ❀ 執行上下文棧(執行棧)
執行上下文棧(下文簡稱執行棧)也叫調用棧，執行棧用於存儲代碼執行期間創建的所有上下文，具有LIFO（Last In First Out后進先出，也就是先進后出）的特性。
JS代碼首次運行，都會先創建一個全局執行上下文並壓入到執行棧中，之后每當有函數被調用，都會創建一個新的函數執行上下文並壓入棧內；由於執行棧LIFO的特性，所以可以理解為，JS代碼執行完畢前在執行棧底部永遠有個全局執行上下文。
function f1() { f2(); console.log(1); }; function f2() { f3(); console.log(2); }; function f3() { console.log(3); }; f1();//3 2 1
我們通過執行棧與上下文的關系來解釋上述代碼的執行過程，為了方便理解，我們假象執行棧是一個數組，在代碼執行初期一定會創建全局執行上下文並壓入棧，因此過程大致如下：
//代碼執行前創建全局執行上下文 ECStack = [globalContext]; // f1調用 ECStack.push('f1 functionContext'); // f1又調用了f2，f2執行完畢之前無法console 1 ECStack.push('f2 functionContext'); // f2又調用了f3，f3執行完畢之前無法console 2 ECStack.push('f3 functionContext'); // f3執行完畢，輸出3並出棧 ECStack.pop(); // f2執行完畢，輸出2並出棧 ECStack.pop(); // f1執行完畢，輸出1並出棧 ECStack.pop(); // 此時執行棧中只剩下一個全局執行上下文
那么到這里，我們解釋了執行棧與執行上下文的存儲規則；還記得我在前文提到代碼執行前JS引擎會做准備創建執行上下文嗎，具體怎么創建呢，我們接着說。
肆 ❀ 執行上下文創建階段
執行上下文創建分為創建階段與執行階段兩個階段，較為難理解應該是創建階段，我們先說創建階段。
JS執行上下文的創建階段主要負責三件事：確定this---創建詞法環境組件（LexicalEnvironment）---創建變量環境組件（VariableEnvironment）
這里我就直接借鑒了他人翻譯資料的偽代碼，來表示這個創建過程：
ExecutionContext = { // 確定this的值 ThisBinding = <this value>, // 創建詞法環境組件 LexicalEnvironment = {}, // 創建變量環境組件 VariableEnvironment = {}, };
如果你有閱讀其它關於執行上下文的文章讀到這里一定有疑問，執行上下文創建過程不是應該解釋this，作用域與變量對象/活動對象才對嗎，怎么跟別的地方說的不一樣，這點我后面解釋。
1.確定this
官方的稱呼為This Binding，在全局執行上下文中，this總是指向全局對象，例如瀏覽器環境下this指向window對象。
而在函數執行上下文中，this的值取決於函數的調用方式，如果被一個對象調用，那么this指向這個對象。否則this一般指向全局對象window或者undefined（嚴格模式）。
我在之前有專門寫一篇介紹this的博文，現在看來寫的很不好，之后我會重新理解寫一篇通俗易懂的文章。
this文章已更新--2019.12.3： js 五種綁定徹底弄懂this，默認綁定、隱式綁定、顯式綁定、new綁定、箭頭函數綁定詳解
2.詞法環境組件
詞法環境是一個包含標識符變量映射的結構，這里的標識符表示變量/函數的名稱，變量是對實際對象【包括函數類型對象】或原始值的引用。
詞法環境由環境記錄與對外部環境引入記錄兩個部分組成。
其中環境記錄用於存儲當前環境中的變量和函數聲明的實際位置；外部環境引入記錄很好理解，它用於保存自身環境可以訪問的其它外部環境，那么說到這個，是不是有點作用域鏈的意思？
我們在前文提到了全局執行上下文與函數執行上下文，所以這也導致了詞法環境分為全局詞法環境與函數詞法環境兩種。
全局詞法環境組件：
對外部環境的引入記錄為null，因為它本身就是最外層環境，除此之外它還記錄了當前環境下的所有屬性、方法位置。
函數詞法環境組件：
包含了用戶在函數中定義的所有屬性方法外，還包含了一個arguments對象。函數詞法環境的外部環境引入可以是全局環境，也可以是其它函數環境，這個根據實際代碼而來。
這里借用譯文中的偽代碼（環境記錄在全局和函數中也不同，全局中的環境記錄叫對象環境記錄，函數中環境記錄叫聲明性環境記錄，說多了糊塗，下方有展示）：
// 全局環境 GlobalExectionContext = { // 全局詞法環境 LexicalEnvironment: { // 環境記錄 EnvironmentRecord: { Type: "Object", //類型為對象環境記錄 // 標識符綁定在這里 }, outer: < null > } }; // 函數環境 FunctionExectionContext = { // 函數詞法環境 LexicalEnvironment: { // 環境紀錄 EnvironmentRecord: { Type: "Declarative", //類型為聲明性環境記錄 // 標識符綁定在這里 }, outer: < Global or outerfunction environment reference > } };
3.變量環境組件
變量環境可以說也是詞法環境，它具備詞法環境所有屬性，一樣有環境記錄與外部環境引入。在ES6中唯一的區別在於詞法環境用於存儲函數聲明與let const聲明的變量，而變量環境僅僅存儲var聲明的變量。
我們通過一串偽代碼來理解它們：
let a = 20; const b = 30; var c; function multiply(e, f) { var g = 20; return e * f * g; } c = multiply(20, 30);
我們用偽代碼來描述上述代碼中執行上下文的創建過程：
//全局執行上下文 GlobalExectionContext = { // this綁定為全局對象 ThisBinding: <Global Object>, // 詞法環境 LexicalEnvironment: { //環境記錄 EnvironmentRecord: { Type: "Object", // 對象環境記錄 // 標識符綁定在這里 let const創建的變量a b在這 a: < uninitialized >, b: < uninitialized >, multiply: < func > } // 全局環境外部環境引入為null outer: <null> }, VariableEnvironment: { EnvironmentRecord: { Type: "Object", // 對象環境記錄 // 標識符綁定在這里 var創建的c在這 c: undefined, } // 全局環境外部環境引入為null outer: <null> } } // 函數執行上下文 FunctionExectionContext = { //由於函數是默認調用 this綁定同樣是全局對象 ThisBinding: <Global Object>, // 詞法環境 LexicalEnvironment: { EnvironmentRecord: { Type: "Declarative", // 聲明性環境記錄 // 標識符綁定在這里 arguments對象在這 Arguments: {0: 20, 1: 30, length: 2}, }, // 外部環境引入記錄為</Global> outer: <GlobalEnvironment> }, VariableEnvironment: { EnvironmentRecord: { Type: "Declarative", // 聲明性環境記錄 // 標識符綁定在這里 var創建的g在這 g: undefined }, // 外部環境引入記錄為</Global> outer: <GlobalEnvironment> } }
不知道你有沒有發現，在執行上下文創建階段，函數聲明與var聲明的變量在創建階段已經被賦予了一個值，var聲明被設置為了undefined，函數被設置為了自身函數，而let const被設置為未初始化。
現在你總知道變量提升與函數聲明提前是怎么回事了吧，以及為什么let const為什么有暫時性死域，這是因為作用域創建階段JS引擎對兩者初始化賦值不同。
上下文除了創建階段外，還有執行階段，這點大家應該好理解，代碼執行時根據之前的環境記錄對應賦值，比如早期var在創建階段為undefined，如果有值就對應賦值，像let const值為未初始化，如果有值就賦值，無值則賦予undefined。
伍 ❀ 關於變量對象與活動對象
回答前面的問題，為什么別人的博文介紹上下文都是談作用域，變量對象和活動對象，我這就成了詞法環境，變量環境了。
我在閱讀相關資料也產生了這個疑問，一番查閱可以確定的是，變量對象與活動對象的概念是ES3提出的老概念，從ES5開始就用詞法環境和變量環境替代了，因為更好解釋。
在上文中，我們通過介紹詞法環境與變量環境解釋了為什么var會存在變量提升，為什么let const沒有，而通過變量對象與活動對象是很難解釋的，由其是在JavaScript在更新中不斷在彌補當初設計的坑。
其次，詞法環境的概念與變量對象這類概念也是可以對應上的。
我們知道變量對象與活動對象其實都是變量對象，變量對象是與執行上下文相關的數據作用域，存儲了在上下文中定義的變量和函數聲明。而在函數上下文中，我們用活動對象(activation object, AO)來表示變量對象。
那這不正好對應到了全局詞法記錄與函數詞法記錄了嗎。而且由於ES6新增的let const不存在變量提升，於是正好有了詞法環境與變量環境的概念來解釋這個問題。
所以說到這，你也不用為詞法環境，變量對象的概念鬧沖突了。
我們來總結下上面提到的概念。
陸 ❀ 總結
1.全局執行上下文一般由瀏覽器創建，代碼執行時就會創建；函數執行上下文只有函數被調用時才會創建，調用多少次函數就會創建多少上下文。
2.調用棧用於存放所有執行上下文，滿足FILO規則。
3.執行上下文創建階段分為綁定this，創建詞法環境，變量環境三步，兩者區別在於詞法環境存放函數聲明與const let聲明的變量，而變量環境只存儲var聲明的變量。
4.詞法環境主要由環境記錄與外部環境引入記錄兩個部分組成，全局上下文與函數上下文的外部環境引入記錄不一樣，全局為null，函數為全局環境或者其它函數環境。環境記錄也不一樣，全局叫對象環境記錄，函數叫聲明性環境記錄。
5.你應該明白了為什么會存在變量提升，函數提升，而let const沒有。
6.ES3之前的變量對象與活動對象的概念在ES5之后由詞法環境，變量環境來解釋，兩者概念不沖突，后者理解更為通俗易懂。
不得不說相關文章也是看的我心累，也希望對有緣的你有所幫助，那么到這里，本文結束。
柒 ❀ 參考