這篇在講什麼
在 C# 裡,整數型別不只一種。byte、short、int、long 都能表示整數,但它們的範圍、大小和使用成本不一樣。
這篇在整理一個很實務的問題:什麼時候該優先用 int,什麼時候才值得為了空間改用更小的型別。
先把常見整數型別看清楚
最常見的幾種如下:
byte: 1 byte,0到255sbyte: 1 byte,-128到127short: 2 bytes,-32,768到32,767ushort: 2 bytes,0到65,535int: 4 bytesuint: 4 byteslong: 8 bytesulong: 8 bytes
只看單一欄位大小,確實可以得到一個很直觀的結論:型別越小,單個值占用的空間通常越小。
什麼情況下小型別真的能省空間
真正有感的情境通常是:
- 很大的陣列
- 大量 struct 實例
- 原生 buffer
- 封包或序列化格式對大小很敏感
例如:
- 一百萬個
int大約是 4 MB - 一百萬個
short大約是 2 MB
當資料量非常大時,差距就會開始明顯。
但不是所有情況都值得為了省空間改小型別
這裡最容易踩的誤區是:看到 byte 或 short 比 int 小,就以為一定更划算。
實際上不一定,原因包括:
- 很多 API 預設就是用
int - CPU 對
int的處理通常更自然 - 小型別經常伴隨額外轉型
- struct 內部還可能受到對齊和 padding 影響
也就是說,欄位看起來變小,不代表整體資料結構一定等比例變小。
為什麼 int 通常還是預設選擇
在多數一般商業程式和遊戲程式裡,int 通常仍然是最穩定的預設:
- 範圍夠大
- API 相容性高
- 算術運算最省事
- 可讀性通常更好
像索引、計數、一般數值狀態,如果沒有很強的空間壓力,直接用 int 往往是最乾淨的做法。
什麼時候才值得刻意選小型別
只有在你很清楚資料上限,而且總量真的夠大時,才值得主動考慮:
- 數值範圍非常明確,例如
0到255 - 會放進大量陣列或 buffer
- 封包、存檔、原生記憶體配置對大小敏感
- 這個欄位在效能或空間分析中已經被證明是熱點
這種時候選 byte 或 short 是有根據的設計,不是憑感覺做微優化。
struct 內部大小不能只看欄位型別
如果你真的在做空間優化,不能只看語法層的型別名稱,還要看最終的資料布局。
需要注意的包含:
- 欄位排列順序
- CLR 對齊策略
- padding
- 陣列元素的實際布局
有時候把某個欄位從 int 改成 byte,最後整個 struct 的大小根本沒變。
我自己的整理
整數型別選擇的優先順序,通常應該是:
- 先保證語意正確
- 再保證可讀性和一致性
- 只有在資料量和空間壓力夠大時,才做小型別優化
換句話說,int 是合理預設,小型別是有條件的優化工具。
先記住的重點
int通常是整數型別的合理預設- 小型別只有在大量資料情境下才比較容易帶來實際收益
- 欄位變小,不代表整體結構一定等比例縮小
- 真正在做空間優化時,要看完整資料布局,不要只看型別名稱
- 沒有明確證據時,優先選擇可讀性和一致性