關于js的作用域鏈，早有耳聞，也曾看過幾篇介紹性的博文，但一直都理解的模棱兩可。近日又精心翻看了一下《悟透Javascript》這本書，覺得寫得太深刻，在“代碼的時空”一節里有一段介紹作用域鏈的地方寥寥數語，回味無窮（其實還是理解的模棱兩可^_^）。現在整理下自己的讀書筆記，順便借鑒網上資源，寫下來。

一、從一個簡單的問題說起

下面的js代碼在頁面中運行顯示什么結果：

您的答案是什么？沒錯，就是彈出10。我的理解是這樣的，funTest函數有一個形參arg，funTest函數傳入實參10，alert方法把10彈出就是了，囧。
好，問題又來了：

答案是什么？如果是5年前的我，肯定不會再往下想了，還是10！這么簡單的問題還用想什么呀？我的理解是這樣的：funTest函數是一個無參數的函數，函數內部通過alert方法，調用外部（全局）的變量arg,在函數執行前，arg賦值為10，彈出arg值后改變arg值為2，所以彈出值為10。

真的是10嗎？是還是不是？

測試的結果：彈出“undefined”,瀑布汗.

二、理解作用域鏈，從javascript運行機制說起

1、js的運行順序

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

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

上面的分析已經足夠清楚，步驟二、三和步驟四里的紅色字體可能是我們新手理解上的一個盲點，尤其是步驟三的“預解析”，如果不清楚什么叫預解析，總覺得不踏實。而步驟四的“有錯則報錯”也是經常碰到的。舉例來說：

上面這段代碼執行時，彈出“undefined”，也就是說arg沒有定義，js的變量不是不用定義也可以嗎？

2、語法分析和“預解析”

（1）、從解釋型語言的編譯過程說起

眾所周知，javascript是解釋型語言，它不同于c#和java等編譯型語言。對于傳統編譯型語言來說，編譯步驟分為：詞法分析、語法分析、語義檢查、代碼優化和字節生成；但對于解釋型語言來說，通過詞法分析和語法分析得到語法樹后，就可以開始解釋執行了。

a、詞法分析

簡單地說，詞法分析是將字符流(char stream)轉換為記號流(token stream)。
但是這個轉換過程并不是可以用一句話就可以概括的那么簡單，我們可以試著用偽代碼理解一段簡單的程序：

代碼var result=x-y;的轉換大致可以表示如下：

NAME "result"
EQUALS
NAME "x"
MINUS
NAME "y"
SEMICOLON

b、語法分析

簡單地說，語法分析就是為了構造合法的語法分析樹，而語法分析樹可以直觀地表示出推導的過程。

那么什么是語法分析樹？簡單地說，就是程序推導過程的描述。但是到底什么是語法樹，請參考專業文章，本篇略過。

c、其他

通過語法分析，構造出語法分析樹后，接下來還可能需要進一步的語義檢查。對于傳統強類型語言來說，語義檢查的主要部分是類型檢查，比如函數的實參和形參類型是否匹配等等。
結論：通過上面的分析可以看出，對于javascript引擎來說，肯定有詞法分析和語法分析，之后可能還有語義檢查、代碼優化等步驟，等這些編譯步驟完成之后（任何語言都有編譯過程，只是解釋型語言沒有編譯成二進制代碼），才會開始執行代碼。

（2）、執行過程

a、javascript的作用域機制

通過編譯，javascript代碼已經翻譯成了語法樹，然后會立刻按照語法樹執行。

進一步的執行過程，需要理解javascript的作用域機制：詞法作用域（lexcical scope）。通俗地講，就是javascript變量的作用域是在定義時決定而不是執行時決定，也就是說詞法作用域取決于源碼，編譯器通過靜態分析就能確定，因此詞法作用域也叫做靜態作用域（static scope）。但需要注意，with和eval的語義無法僅通過靜態技術實現，所以只能說javascript的作用域機制非常接近詞法作用域（lexical scope）.

javascript引擎在執行每個函數實例時，都會創建一個執行環境（execution context）。執行環境中包含一個調用對象（call object）, 調用對象是一個scriptObject結構（scriptObject是與函數相關的一套靜態系統，與函數實例的生命周期保持一致），用來保存內部變量表varDecls、內嵌函數表funDecls、父級引用列表upvalue等語法分析結構（注意varDecls和funDecls等信息是在語法分析階段就已經得到，并保存在語法樹中。函數實例執行時，會將這些信息從語法樹復制到scriptObject上）。

b、javascript作用域機制的實現方法

詞法作用域（lexical scope）是javascript的作用域機制，還需要理解它的實現方法，就是作用域鏈（scope chain）。作用域鏈是一個name lookup機制，首先在當前執行環境的scriptObject中尋找，沒找到，則順著upvalue到父scriptObject中尋找，一直lookup到全局調用對象（global object）。

現在回過頭來分析第二個問題：

在執行funcTest函數時，也即進入了funcTest對應的作用域，js引擎在執行時，當遇到對變量名或者函數名的使用時，會首先在當前作用域（也即funcTest對應的作用域）查找變量或者函數（顯然，arg變量在funcTest對應的作用域里被定義為var arg=2 所以alert方法的參數采用的是當前作用域的arg，但是因為arg被定義在alert方法后，所以arg變量默認值為undefined）。當然，如果沒有找到就到上層作用域查找，依此類推（作用域范圍可以持續到javascript運行環境的根：window對象）。

最后，讓你看的更清楚，上面的代碼其實可以等價于：

c、閉包（closure）

當一個函數實例執行時，會創建或關聯到一個閉包。 （關于閉包，打算另寫一篇學習筆記）

scriptObject用來靜態保存與函數相關的變量表，閉包則在執行期動態保存這些變量表及其運行值；

閉包的生命周期有可能比函數實例長。函數實例在活動引用為空后會自動銷毀；

閉包則要等要數據引用為空后，由javascript引擎回收（有些情況下不會自動回收，就導致了內存泄漏）。

ps：關于“執行過程”這一段比較拗口，名詞很多，不過別被它們嚇住，一旦理解了執行環境（execution context）、調用對象（call object）、詞法作用域（lexical scope）、作用域鏈（scope chain）、閉包（closure）等這些概念，javascript的很多現象都能迎刃而解。

三、結語

通過第二段的分析，對照第一段筆者曾經做出的判斷(你是不是也覺得筆者曾經的分析和結論很幼稚（哪怕有時結果碰巧也對！）？！不是一般的膚淺啊，^_^)，你會發現原來javascript還有這么多“玄機”，而要真正理解精通又談何容易？先“悟透”再說吧。

希望本文所述對大家JavaScript程序設計有所幫助。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com