昨天，我知道了一件以前從來沒想過的事情。

CPU 根本看不懂我寫的 C#。

真正執行程式之前，還會經過 Compiler、IL、JIT 等許多步驟。

但新的疑問又出現了。

如果 CPU 看不懂 C#，那到底是誰看得懂？

很多資料都說：

Compiler。

可是新的 Why 又來了 Compiler 到底是什麼？

它真的只是一本翻譯字典嗎？

Compiler 到底是什麼？

我以前一直以為：

Compiler 就像 Google 翻譯。

把 C# 翻譯成另一種語言。

但是查了資料後，我發現事情沒有這麼簡單。

使用Visual studio 執行

Console.WriteLine("Hello World"

會清楚看到程式失敗

問題來了

CPU 有看到這段程式嗎？

答案： 沒有。

Compiler 在第一關就把它攔下來了。

把程式改成

int number = "Hello";

再 Build後又失敗。

這次不是語法錯誤而是型別錯誤（Type Checking）
所以我開始理解：

Compiler 並不是翻譯機，而比較像一位非常嚴格的老師

它每天都在做：

• 檢查語法

• 檢查型別

• 找出錯誤

• 決定能不能進入下一個階段

如果沒有通過程式甚至沒有機會交給 CPU。
官方怎麼說？

完成今天的兩個實驗後，我開始思考：

如果 Compiler 真的只是「翻譯器」，那它為什麼能在程式還沒執行之前，就發現括號少一個、或是型別不符合等錯誤？

於是，我查閱了 Microsoft 官方文件。

https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/compiler-api-model?utm_source=chatgpt.com

官方指出，Compiler 並不是單純將程式碼轉換成另一種語言，而是會先建立程式的完整模型，並依序進行語法（Syntax）分析、語意（Semantic）分析等步驟，確認程式是否合法，最後才產生編譯後的輸出。

這也解釋了今天的兩個實驗：

少一個括號時，Compiler 在語法分析階段就停止編譯。
型別不符合時，Compiler 在語意分析階段就發現問題，因此同樣無法完成編譯。

換句話說，Compiler 不只是翻譯程式，更像是一位嚴格的審查員。 它會先確認程式是否符合 C# 的規則，只有全部通過後，才會繼續產生後續的編譯成果。

今天以前，我一直以為 Compiler 的工作只有一件事：

把 C# 翻譯成另一種語言。

但透過今天的實驗，再對照 Microsoft 官方文件，我發現自己的理解太淺了。

Compiler 真正的工作其實是：

-理解 我寫的 C# 程式。
-檢查 語法是否正確。
-分析 型別與程式語意是否合理。
-確認 沒有錯誤後，才開始產生編譯結果（例如 IL）。 *IL（Intermediate Language）

所以 CPU 根本沒有機會看到那些寫錯的程式碼，因為 Compiler 在第一關就已經把它們攔了下來。

今天我最大的收穫，不是知道 Compiler 的定義，而是理解它真正扮演的角色。

以前我以為，Compiler 的工作只是把 C# 轉換成另一種語言。

但今天透過兩個小實驗，我發現它更像是程式的第一位守門員。

它會先檢查程式是否符合語法、型別是否正確，只有全部通過後，才會開始產生 IL，讓程式進入下一個執行階段。

也就是說，CPU 根本沒有機會看到那些寫錯的程式碼，因為 Compiler 早就把它攔下來了。
今天雖然沒有開始撰寫 Framework 的程式碼。

但我開始理解了一件重要的事情。

未來當我們建立自己的 Framework 時，每一次按下 Build，都會經過 Compiler 的檢查與編譯。

如果不了解 Compiler 的角色，我們就很難真正理解 Framework 是如何一步步被建構出來的。

所以今天的內容，其實是在替之後的 Framework 打地基。

下一個 Why

今天，我知道了 Compiler 並不是單純的翻譯器，而是程式的第一位守門員。只有通過它的檢查，我的程式才有機會進入下一個階段。

但新的疑問又出現了。

當我按下 Build 時，Compiler 到底做了哪些事情？為什麼專案裡會突然多出 bin、obj、.dll 等檔案？這些檔案又各自代表什麼？

下一篇，我想從 Build 開始，一步一步拆解編譯過程，看看我的程式究竟發生了哪些變化。