大家應該寫過上面類似的代碼吧，其實這里我想要表達的是有時候一個方法定義的地方和使用的地方會相隔十萬八千里，那方法執(zhí)行時，它能訪問哪些變量，不能訪問哪些變量，這個怎么判斷呢？這個就是我們這次需要分析的問題—詞法作用域

詞法作用域：變量的作用域是在定義時決定而不是執(zhí)行時決定，也就是說詞法作用域取決于源碼，通過靜態(tài)分析就能確定，因此詞法作用域也叫做靜態(tài)作用域。 with和eval除外，所以只能說JS的作用域機制非常接近詞法作用域（Lexical scope）。


下面通過幾個小小的案例，開始深入的了解對理解詞法作用域和閉包必不可少的，JS執(zhí)行時底層的一些概念和理論知識。

經(jīng)典案列重現(xiàn)
1、經(jīng)典案例一

疑問：上面的代碼會輸出什么呢？
答案：沒錯，就是彈出10。具體執(zhí)行過程應該是這樣的

a 函數(shù)有一個形參 i，調(diào)用 a 函數(shù)時傳入實參 10，形參 i=10
接著定義一個同名的局部變量 i，未賦值
alert 輸出 10
思考：局部變量 i 和形參 i 是同一個存儲空間嗎？
2、經(jīng)典案例二

疑問：上面的代碼又會輸出什么呢？（（ 10,10,2,10 10,10,2,2 ））
答案：在FireBug中的運行結果是第二個10,10,2,2，猜對了… ，下面簡單說一下具體執(zhí)行過程

a 函數(shù)有一個形參i，調(diào)用 a 函數(shù)時傳入實參 10，形參 i=10
第一個 alert 把形參 i 的值 10 輸出
第二個 alert 把 arguments[0] 輸出，應該也是 i
接著定義個局部變量 i 并賦值為2，這時候局部變量 i=2
第三個 alert 就把局部變量 i 的值 2 輸出
第四個alert再次把 arguments[0] 輸出
思考：這里能說明局部變量 i 和形參 i 的值相同嗎？
3、經(jīng)典案例三

疑問：上面的代碼又又會輸出什么呢？（（ undefined 10 ））
答案：在FireBug中的運行結果是 10，下面簡單說一下具體執(zhí)行過程

第一句聲明一個與形參 i 同名的局部變量 i，根據(jù)結果我們知道，后一個 i 是指向了
形參 i，所以這里就等于把形參 i 的值 10 賦了局部變量 i
第二個 alert 當然就輸出 10
思考：結合案列二，這里基本能說明局部變量 i 和形參 i 指向了同一個存儲地址！
4、經(jīng)典案例四

疑問：上面的代碼又會輸出什么呢？（小子，看這回整不死你！哇哈哈，就不給你選項）
答案：在FireBug中的運行結果是 undefined, 2，下面簡單說一下具體執(zhí)行過程

第一個alert輸出undefined
第二個alert輸出 2
思考：到底怎么回事兒？
5、經(jīng)典案例五…………..N
看到上面的幾個例子，你可能會想，怎么可能，我寫了幾年的 js 了，怎么這么簡單例子也會猶豫，結果可能還答錯了。其實可能原因是：我們能很快的寫出一個方法，但到底方法內(nèi)部是怎么執(zhí)行的呢？執(zhí)行的細節(jié)又是怎么樣的呢？你可能沒有進行過深入的學習和了解。要了解這些細節(jié)，那就需要了解 JS 引擎的工作方式，所以下面我們就把 JS 引擎對一個方法的解析過程進行一個稍微深入一些的介紹

解析過程

1、執(zhí)行順序

• 編譯型語言，編譯步驟分為：詞法分析、語法分析、語義檢查、代碼優(yōu)化和字節(jié)生成。
• 解釋型語言，通過詞法分析和語法分析得到語法分析樹后，就可以開始解釋執(zhí)行了。這里是一個簡單原始的關于解析過程的原理，僅作為參考，詳細的解析過程（各種JS引擎還有不同）還需要更深一步的研究

JavaScript執(zhí)行過程，如果一個文檔流中包含多個script代碼段（用script標簽分隔的js代碼或引入的js文件），它們的運行順序是：

1. 步驟1. 讀入第一個代碼段（js執(zhí)行引擎并非一行一行地執(zhí)行程序，而是一段一段地分析執(zhí)行的）
2. 步驟2. 做詞法分析和語法分析，有錯則報語法錯誤（比如括號不匹配等），并跳轉到步驟5
3. 步驟3. 對【var】變量和【function】定義做“預解析“（永遠不會報錯的，因為只解析正確的聲明）
4. 步驟4. 執(zhí)行代碼段，有錯則報錯（比如變量未定義）
5. 步驟5. 如果還有下一個代碼段，則讀入下一個代碼段，重復步驟2
6. 步驟6. 結束

2、特殊說明
全局域（window）域下所有JS代碼可以被看成是一個“匿名方法“，它會被自動執(zhí)行，而此“匿名方法“內(nèi)的其它方法則是在被顯示調(diào)用的時候才被執(zhí)行
3、關鍵步驟
上面的過程，我們主要是分成兩個階段

1. 解析：就是通過語法分析和預解析構造合法的語法分析樹。
2. 執(zhí)行：執(zhí)行具體的某個function，JS引擎在執(zhí)行每個函數(shù)實例時，都會創(chuàng)建一個執(zhí)行環(huán)境（ExecutionContext）和活動對象（activeObject）（它們屬于宿主對象，與函數(shù)實例的生命周期保持一致）

3、關鍵概念
到這里，我們再更強調(diào)以下一些概念，這些概念都會在下面用一個一個的實體來表示，便于大家理解

• 語法分析樹（SyntaxTree）可以直觀地表示出這段代碼的相關信息,具體的實現(xiàn)就是JS引擎創(chuàng)建了一些表，用來記錄每個方法內(nèi)的變量集（variables），方法集（functions）和作用域（scope）等
• 執(zhí)行環(huán)境（ExecutionContext）可理解為一個記錄當前執(zhí)行的方法【外部描述信息】的對象,記錄所執(zhí)行方法的類型，名稱，參數(shù)和活動對象（activeObject）
• 活動對象（activeObject）可理解為一個記錄當前執(zhí)行的方法【內(nèi)部執(zhí)行信息】的對象,記錄內(nèi)部變量集（variables）、內(nèi)嵌函數(shù)集（functions）、實參（arguments）、作用域鏈（scopeChain）等執(zhí)行所需信息，其中內(nèi)部變量集（variables）、內(nèi)嵌函數(shù)集（functions）是直接從第一步建立的語法分析樹復制過來的
• 詞法作用域：變量的作用域是在定義時決定而不是執(zhí)行時決定，也就是說詞法作用域取決于源碼，通過靜態(tài)分析就能確定，因此詞法作用域也叫做靜態(tài)作用域。 with和eval除外，所以只能說JS的作用域機制非常接近詞法作用域（Lexical scope）
• 作用域鏈：詞法作用域的實現(xiàn)機制就是作用域鏈（scopeChain）。作用域鏈是一套按名稱查找（Name Lookup）的機制，首先在當前執(zhí)行環(huán)境的 ActiveObject 中尋找，沒找到，則順著作用域鏈到父 ActiveObject 中尋找，一直找到全局調(diào)用對象（Global Object）

4、實體表示

解析模擬

估計，看到這兒，大家還是很朦朧吧，什么是語法分析樹，語法分析樹到底長什么樣子，作用域鏈又怎么實現(xiàn)的，活動對象又有什么內(nèi)容等等，還是不是太清晰，下面我們就通過一段實際的代碼來模擬整個解析過程，我們就把語法分析樹，活動對象實實在在的創(chuàng)建出來，理解作用域，作用域鏈的到底是怎么實現(xiàn)的

1、模擬代碼

2、語法分析樹
上面的代碼很簡單，就是先定義了一些全局變量和全局方法，接著在方法內(nèi)再定義局部變量和局部方法，現(xiàn)在JS解釋器讀入這段代碼開始解析，前面提到 JS 引擎會先通過語法分析和預解析得到語法分析樹，至于語法分析樹長什么樣兒，都有些什么信息，下面我們以一種簡單的結構：一個 JS 對象(為了清晰表示個各種對象間的引用關系，這里的只是偽對象表示，可能無法運行)來描述語法分析樹（這是我們比較熟悉的，實際結構我們不去深究，肯定復雜得多，這里是為了幫助理解解析過程而特意簡化）

上面就是關于語法分析樹的一個簡單表示，正如我們前面分析的，語法分析樹主要記錄了每個 function 中的變量集（variables），方法集（functions）和作用域（scope）
語法分析樹關鍵點

1變量集（variables）中，只有變量定義，沒有變量值，這時候的變量值全部為“undefined”
2作用域（scope），根據(jù)詞法作用域的特點，這個時候每個變量的作用域就已經(jīng)明確了，而不會隨執(zhí)行時的環(huán)境而改變?！臼裁匆馑寄?？就是我們經(jīng)常將一個方法 return 回去，然后在另外一個方法中去執(zhí)行，執(zhí)行時，方法中變量的作用域是按照方法定義時的作用域走。其實這里想表達的意思就是不管你在多么復雜，多么遠的地方執(zhí)行該方法，最終判斷方法中變量能否被訪問還是得回到方法定義時的地方查證】
3作用域（scope）建立規(guī)則
a對于函數(shù)聲明和匿名函數(shù)表達式來說，[scope]就是它創(chuàng)建時的作用域
b對于有名字的函數(shù)表達式，[scope]頂端是一個新的JS對象（也就是繼承了Object.prototype），這個對象有兩個屬性，第一個是自身的名稱，第二個是定義的作用域，第一個函數(shù)名稱是為了確保函數(shù)內(nèi)部的代碼可以無誤地訪問自己的函數(shù)名進行遞歸。
3、執(zhí)行環(huán)境與活動對象
語法分析完成，開始執(zhí)行代碼。我們調(diào)用每一個方法的時候，JS 引擎都會自動為其建立一個執(zhí)行環(huán)境和一個活動對象，它們和方法實例的生命周期保持一致，為方法執(zhí)行提供必要的執(zhí)行支持，針對上面的幾個方法，我們這里統(tǒng)一為其建立了活動對象（按道理是在執(zhí)行方法的時候才會生成活動對象，為了便于演示，這里一下子定義了所有方法的活動對象），具體如下：
執(zhí)行環(huán)境

上面每一個方法的執(zhí)行環(huán)境都存儲了相應方法的類型（function）、方法名稱（funcName）、活動對象（ActiveObject）、作用域鏈（scopeChain）等信息,其關鍵點如下：

body屬性，直接指向當前方法的活動對象
scopeChain屬性，作用域鏈，它是一個鏈表結構，根據(jù)語法分析樹中當前方法對應的scope屬性，它指向scope對應的方法的活動對象（ActivceObject），變量查找就是跟著這條鏈條查找的
活動對象

上面每一個活動對象都存儲了相應方法的內(nèi)部變量集（variables）、內(nèi)嵌函數(shù)集（functions）、形參（parameters）、實參（arguments）等執(zhí)行所需信息，活動對象關鍵點

創(chuàng)建活動對象，從語法分析樹復制方法的內(nèi)部變量集（variables）和內(nèi)嵌函數(shù)集（functions）
方法開始執(zhí)行，活動對象里的內(nèi)部變量集全部被重置為 undefined
創(chuàng)建形參（parameters）和實參（arguments）對象，同名的實參，形參和變量之間是【引用】關系
執(zhí)行方法內(nèi)的賦值語句，這才會對變量集中的變量進行賦值處理
變量查找規(guī)則是首先在當前執(zhí)行環(huán)境的 ActiveObject 中尋找，沒找到，則順著執(zhí)行環(huán)境中屬性 ScopeChain 指向的 ActiveObject 中尋找，一直到 Global Object（window）
方法執(zhí)行完成后，內(nèi)部變量值不會被重置，至于變量什么時候被銷毀，請參考下面一條
方法內(nèi)變量的生存周期取決于方法實例是否存在活動引用，如沒有就銷毀活動對象
6和7 是使閉包能訪問到外部變量的根本原因
重釋經(jīng)典案例
案列一二三

根據(jù)【在一個方法中，同名的實參，形參和變量之間是引用關系，也就是JS引擎的處理是同名變量和形參都引用同一個內(nèi)存地址】，所以才會有二中的修改arguments會影響到局部變量的情況出現(xiàn)

案例四

根據(jù)【JS引擎變量查找規(guī)則，首先在當前執(zhí)行環(huán)境的 ActiveObject 中尋找，沒找到，則順著執(zhí)行環(huán)境中屬性 ScopeChain 指向的 ActiveObject 中尋找，一直到 Global Object（window）】，所以在四中，因為在當前的ActiveObject中找到了有變量 i 的定義，只是值為 “undefined”，所以直接輸出 “undefined” 了

總結
以上是我在學習和使用了JS一段時間后,為了更深入的了解它, 也為了更好的把握對它的應用, 從而在對閉包的學習過程中,自己對于詞法作用域的一些理解和總結,中間可能有一些地方和真實的JS解釋引擎有差異,因為我只是站在一個剛入門的前端開發(fā)人員而不是系統(tǒng)設計者的角度上去分析這個問題，希望能對JS開發(fā)者理解此法作用域帶來一些幫助！