我們知道，在匿名方法或者lambda中，可以訪問或者修改該匿的定義范圍內的變量。例如：
int num = 1;
Func<int> incNum = () => ++num;
其中lambda表達式使用了在其外部定義的變量num。我們可以認為該段lambda語句塊構成了一個閉包，而這個閉包捕獲了外部變量num。
好了，不說那麼多讓人看著難受的定義套話了。我們進入正題，看看在C#中變量是如何被捕獲的。來看一個例子：
public Func<String> CreateFunction()
{
String str = "我的幸運數字是";
int num = 17;
Func<String> func = () => str + num;
return func;
}
在這個例子中，定義了一個返回一個函數的方法CreateFunction。返回的函數構成了一個閉包，該閉包捕獲了兩個變量：String類型的str和int類型的num。
好了，我們現在可以這樣使用這個函數了:
Func<String> myFunc = CreateFunction();
String result = myFunc();
我們來分析一下這兩行代碼實際都干了什麼。第一行很容易理解，我們把方法CreateFunction生成的匿名函數賦值給了委托myFunc。第二行更好理解，我們執行了myFunc，並將返回結果賦值給了變量result。我們再深入思考一下：在執行myFunc的時候，會訪問到在CreateFunction中定義兩個變量str與num。雖然這時CreateFunction的棧幀早就被銷毀了，其內部定義的變量至今也“生死不明”了，但是因為我們知道這兩個變量已經被閉包所捕獲了，所以我們堅信這兩個變量截至目前為止還是可以訪問的！
對於str對象，鑒於它是一個引用類型，所以只要有存在某個“東西”一直保存著對它的引用，它就不會被銷毀。這樣我們完全不用擔心在我們需要它時，編譯器或運行時會告訴我們它被弄丟了。然而對於num，情況就有些不同了。num是一個值類型。我們知道值類型是存活在棧上的，我們也知道它所存在的那個棧幀（也就是CreateFunction的幀）在CreateFunction執行完畢後就會被銷毀，然後其上存在的任何值類型也會被一並的銷毀，這其中當然包括我們所關注的變量num了。
那麼，我們為什麼還能安全的訪問num呢？C#中的變量捕獲機制究竟有什麼神奇之處，可以讓值類型擁有違反常規的生存周期呢？裝箱！你可能會立刻想到，把每個值類型都裝到一個對象裡，我們就可以讓這個值類型擁有和那個包裹它的對象相同的壽命了。不過，這並不是C#實現者所選擇的方式！C#並不會對每個需要捕獲的值類型變量進行裝箱操作，而是把所有捕獲的變量統統放到同一個大“箱子”裡——當編譯器遇到需要變量捕獲的情況時，它會默默地在後台構造一個類型，這個類型包含了每一個閉包所捕獲的變量（包括值類型變量和引用類型變量）作為它的一個公有字段。這樣，編譯器就可以
輕松愉快地 維護那些在匿名函數或lambda表達式中出現的外部變量了。 更進一步，如果我們使用ILDASM工具查看CreateFunction方法的IL代碼，我們會發現編譯器壓根就沒有聲明num和str變量。取而代之的是聲明了一個類型名和實例名都及其難看的包裝對象。這個玩意兒就是我們上面所說的那個被編譯器默默生成，保存了所有捕獲變量的引用的對象。我們還可以看到，在 CreateFunction方法 C#源代碼內所有對str和num的操作，在IL中都被轉換成了對包裝對象的同名公有成員的操作。順便說一句，就連我們構造的那個lambda表達式“() => str + num”現在都被編譯器轉換成了這個包裝對象的一個方法！
