C# 基元類型深度解析：從 int 與 Int32 的異同談起

前言：為什麼要了解基元類型？

身為 C# 開發者，我們每天都在使用 int、string、bool 等類型，但真正理解它們背後機制的人卻不多。雖然不懂基元類型不影響日常開發，但在面試、效能優化、與底層互操作等場景中，這份知識卻能讓你脫穎而出。本文將透過實際 IL 代碼驗證，深入剖析 C# 基元類型與 .NET Framework Class Library (FCL) 的映射關係，並解開 int vs Int32、string vs String 等經典疑問。

基元類型的四種寫法，產生的 IL 代碼完全一樣

先看一段常見的程式碼片段：

// 最簡單
int a = 0;
// 較簡潔
Int32 b = 0;
// 不簡潔
int c = new int();
// 最不簡潔
System.Int32 d = new System.Int32();

編譯後查看 IL 代碼（使用 ILDasm 或 dotnet-ildasm）：

.method private hidebysig static void Main(string[] args) cil managed
{
  .entrypoint
  .maxstack 1
  .locals init ([0] int32 a,
                [1] int32 b,
                [2] int32 c,
                [3] int32 d)
  IL_0000: nop
  IL_0001: ldc.i4.0
  IL_0002: stloc.0
  IL_0003: ldc.i4.0
  IL_0004: stloc.1
  IL_0005: ldc.i4.0
  IL_0006: stloc.2
  IL_0007: ldc.i4.0
  IL_0008: stloc.3
  IL_0009: ret
}

結論：四種寫法編譯後全都變成 int32，且皆以 ldc.i4.0 初始化為 0。原因在於 C# 編譯器將基元類型視為 FCL 類型的別名。

C# 基元類型與 FCL、CLS 合規性對照表

表格揭示兩個關鍵事實：

1. 關鍵字只是語法糖：int 編譯時直接對應 System.Int32，兩者在 IL 層面完全等價。
2. CLS 合規性差異：無號整數（uint、ulong 等）不符合 CLS 標準，跨語言互操作時需謹慎使用。

使用 using 別名理解映射關係

若把基元類型視為編譯器內建的 using 別名，即可直觀理解：

using int = System.Int32;
using string = System.String;
using byte = System.Byte;
// ...其他基元類型同理

基元類型之間的隱式轉換：IL 層面的 conv.i8

觀察以下代碼：

Int32 i = 0;
Int64 j = i; // 隱式轉換

對應 IL：

IL_0003: ldloc.0      // 載入 i
IL_0004: conv.i8      // 轉換為 int64
IL_0005: stloc.1      // 存入 j

物件導向視角的疑問：Int32 與 Int64 皆為 struct，無繼承關係，為何能隱式轉換？

答案：這是 CLR 針對基元類型內建的特殊規則。CLR 定義了基元類型之間的隱式/顯式轉換邏輯，並直接在 IL 指令集中提供 conv.* 系列操作碼，繞過一般物件的型別轉換規則。

轉換分類與最佳實務

• 隱式轉換：資料無損失（如 int → long、float → double），直接賦值即可。
• 顯式轉換：可能溢位或精度遺失（如 long → int、double → float），需加括號強制轉型：int x = (int)bigNumber;。

實務建議

1. 慣用 C# 關鍵字（int、string），可讀性較佳，團隊協作一致性高。
2. 跨語言元件、序列化、P/Invoke 時，建議使用 FCL 完整名稱（System.Int32），避免語言差異導致誤解。
3. 避免無意義的 new int()，預設建構函式僅增加語法雜訊，int x = 0; 即可。

總結

基元類型是 C# 與 CLR 類型系統的橋樑。理解其與 FCL 的映射、IL 表現、轉換規則，不僅能應對面試，更能在效能敏感、互操作場景中寫出更精準、可維護的代碼。下次再看到 int vs Int32 的爭論，你已經知道答案：它們在編譯後根本就是同一個東西。