這篇在講什麼

在 C# 裡,整數型別不只一種。byteshortintlong 都能表示整數,但它們的範圍、大小和使用成本不一樣。

這篇在整理一個很實務的問題:什麼時候該優先用 int,什麼時候才值得為了空間改用更小的型別。

先把常見整數型別看清楚

最常見的幾種如下:

  • byte: 1 byte,0255
  • sbyte: 1 byte,-128127
  • short: 2 bytes,-32,76832,767
  • ushort: 2 bytes,065,535
  • int: 4 bytes
  • uint: 4 bytes
  • long: 8 bytes
  • ulong: 8 bytes

只看單一欄位大小,確實可以得到一個很直觀的結論:型別越小,單個值占用的空間通常越小。

什麼情況下小型別真的能省空間

真正有感的情境通常是:

  • 很大的陣列
  • 大量 struct 實例
  • 原生 buffer
  • 封包或序列化格式對大小很敏感

例如:

  • 一百萬個 int 大約是 4 MB
  • 一百萬個 short 大約是 2 MB

當資料量非常大時,差距就會開始明顯。

但不是所有情況都值得為了省空間改小型別

這裡最容易踩的誤區是:看到 byteshortint 小,就以為一定更划算。

實際上不一定,原因包括:

  • 很多 API 預設就是用 int
  • CPU 對 int 的處理通常更自然
  • 小型別經常伴隨額外轉型
  • struct 內部還可能受到對齊和 padding 影響

也就是說,欄位看起來變小,不代表整體資料結構一定等比例變小。

為什麼 int 通常還是預設選擇

在多數一般商業程式和遊戲程式裡,int 通常仍然是最穩定的預設:

  • 範圍夠大
  • API 相容性高
  • 算術運算最省事
  • 可讀性通常更好

像索引、計數、一般數值狀態,如果沒有很強的空間壓力,直接用 int 往往是最乾淨的做法。

什麼時候才值得刻意選小型別

只有在你很清楚資料上限,而且總量真的夠大時,才值得主動考慮:

  • 數值範圍非常明確,例如 0255
  • 會放進大量陣列或 buffer
  • 封包、存檔、原生記憶體配置對大小敏感
  • 這個欄位在效能或空間分析中已經被證明是熱點

這種時候選 byteshort 是有根據的設計,不是憑感覺做微優化。

struct 內部大小不能只看欄位型別

如果你真的在做空間優化,不能只看語法層的型別名稱,還要看最終的資料布局。

需要注意的包含:

  • 欄位排列順序
  • CLR 對齊策略
  • padding
  • 陣列元素的實際布局

有時候把某個欄位從 int 改成 byte,最後整個 struct 的大小根本沒變。

我自己的整理

整數型別選擇的優先順序,通常應該是:

  1. 先保證語意正確
  2. 再保證可讀性和一致性
  3. 只有在資料量和空間壓力夠大時,才做小型別優化

換句話說,int 是合理預設,小型別是有條件的優化工具。

先記住的重點

  • int 通常是整數型別的合理預設
  • 小型別只有在大量資料情境下才比較容易帶來實際收益
  • 欄位變小,不代表整體結構一定等比例縮小
  • 真正在做空間優化時,要看完整資料布局,不要只看型別名稱
  • 沒有明確證據時,優先選擇可讀性和一致性