作為 .Net 開發人員，我們為什麼要學習 CLR？

01-05

作為 .Net 初學者，總是聽見別人說要好好看 CLR via C#，深入了解 CLR，但是作為不了解 CLR的人，並不是很清楚我們為什麼要學習CLR，他對我們開發時甚至不在 .Net 平台開發時能有什麼潛移默化的影響？

不系統學習就要死記硬背，例如方法的參數引用類型和值類型的區別，裝箱拆箱，資源回收，什麼情況下會內存泄漏等等。你需要記住足夠多的特別案例來避免自己掉坑。

系統學習就會讓你有一套方法論，很自然的可以避免這些坑，不用針對每種情況死記硬背。

打個比方你說開車的人是不是都對汽車的內部結構很了解？我相信很多高手對車內部結構雖然沒有機械設計師那麼了解，但應該也是具備相當的知識，他們沒事的時候鬧不好還會自己改裝車玩玩。而且我覺得一個好的車手懂得如何把車的性能逼到極限。但你說我們普通開車的人用了解這些么？我覺得大部分時候開就好了，時間長了雖然比不過職業車手但感覺開的也不錯。甚至對於新手來講，即便給他們講了很多汽車結構的理論知識，估計該犯2的時候還是會2。所以新手最終要的是多開，熟悉車的感覺。可對於開了一段時間車的人來說呢？我覺得雖然沒必要像專業人士懂那麼多，但懂了一點原理後，開的時候聽發動機的聲音，就會發現其實這個地方其實應該少給點油，那個地方其實應該多給點油，這樣開既省油發動機也舒服速度也不慢。這些知識雖然也可以通過經驗積累，但懂得原理後不用栽跟頭也會明白。我想C#和CLR應該也是這個關係，你具備一定語言基礎同時了解了CLR的知識後，你就會開始思考自己的程序為什麼GC壓力這麼大？怎麼很多變數怎麼在gen2里了？自己程序GC pause開銷怎麼這麼大？dynamic type是不錯，但是不是type system query的時間太長了？這麼寫也行，但jit估計優化的不是很好，換種寫法jit沒準能優化的不錯。那些所謂的技巧不也是根據這些來的么？扯了這麼多最後的結論就是如果只是寫代碼，那沒必要懂這麼多古怪的東西，但如果想寫簡潔高效的代碼，懂CLR會事半功倍。

作為一名剛入行或者只是入行了一段時間的初級「軟體工程師」而言，我認為是不需要去學習CLR。一方面來說，微軟做的夠好以至於你可以不必關心底層實現去使用C#、http://VB.NET或者F#等語言，可以在沒有坑的情況下開發出需要的功能；另一方面來說，去了解了CLR之後，對於入門開發者而言也沒有太大幫助，反而會因為網上一些不成熟的言論而礙手礙腳。

但是，當你意識到你需要寫出優秀的代碼，的時候，就需要去了解CLR。你會知道垃圾回收是什麼，知道垃圾回收需要消耗大量性能（在網站高訪問量的時候一個垃圾回收…呵呵），這樣你就會知道為什麼大家讓你不要用「+」加號來拼接字元串，而改用 StringBuilder；你會知道其實 if (!statement) 和 if (statement == false) 這兩個在性能上是完全相同的，因為他們產生的中間代碼是相同的，他們的不同只是在代碼風格和可讀性上；然後你知道為什麼微軟在 Thread 之後提出了 ThreadPool，然後又提出了 Task，其實他們在寫法上沒有太大區別然而在不同場景下有巨大的差別等。

了解代碼的運行機制是寫出優秀代碼的前提，但是就算不去了解你也可以寫完布置下來的任務。

知其然，知其所以然。學什麼東西都是這個理。

CLR via C#還是沒有深入CLR內部, 現在coreclr開源了,期待有人寫出點深入的東西來.

CLR啊，那本書，雖然是神作，但事實上，這本書是不適合初學者看的，要看這本書，你起碼要處於進階的中後期。道理很簡單，當你還不會走路的時候，就別想一百米跨欄的比賽。

唉，我來澆冷水。

所有不能帶源碼調試的軟體、框架或系統，都是耍流氓。因為當你遇到預期與文檔、教程或書的描寫不一致的情況時，你無法進行源碼級驗證。

雖然這個世界上並沒多少人能做到源碼級驗證。

初學者不要看這個。真的。學了一陣子之後再看。

運行時，包括語言特性的實現模型部分，以及關鍵的線程，進程，文件IO，網路IO的模型。沒有運行時，就只剩下Lua了。

最近在看clr和f#，覺得是給自己開闢了另一片天空吧。買了好久今年才有心思靜下心來去看也是慚愧。目前對我的影響是發布程序能夠快速定位bug了…這種影響是潛移默化的?。一同事工作五年，我不知道的他都清楚，可是最近我在勸他看clr，給他講多好多好，他也不會看，過的也挺好的不是?

這不成立，就像PHP看什麼Zend Engine ，其實後期你會感覺到確實有必要

有需要學，有興趣學。沒需要沒興趣學來幹嘛。

建議題主把問題的針對點從「為什麼學習」換成「能學到什麼」。