相同的結構體，服務端和客戶端字節長度差8個字節，咋回事呢？

代碼報了個錯：“byte array size is smaller than the size of the structur”，意思就是byte數組的大小小于結構體的大小，這個錯報出來的原因是我代碼中有個邏輯，需要將byte數組轉換成結構體，但很顯然，我沒有轉換成功，這是咋回事呢？

這個錯報得我莫名其妙的，找了一個小時左右都沒找到問題出在哪，但是最后發現問題的時候，我甚至有些無語。在說清楚問題到底出在哪之前，我們得先了解下代碼的業務邏輯，然后您就知道為什么開始我覺得莫名其妙了！

代碼的業務邏輯是這樣的，我們的業務中有一個服務端和很多個客戶端，客戶端會定期給服務端發送消息，消息是以結構體的形式發送的，當然，在發送消息的時候，需要將結構體轉換成byte數組。

為了確保發送消息的一致性，我特地封裝了一個專門用來處理消息的函數庫，這樣就能確保每個客戶端在發送和接收消息的時候不會出現任何差錯。

但是，差錯偏偏就出現了！在某個客戶端上就出現了文章開頭的那個錯！

經過調試，我發現所有客戶端發送的消息內容都是一樣的，并沒有任何區別。

結構體屬于基本數據類型，因此在定義的時候，長度就已經確定了，我在服務端進行調試，發現結構體的長度為288，但是，服務端接收到的byte數組長度卻只有280，如此一來，在將byte轉換成結構體的時候，因為長度不一致，導致了轉換失敗。

前面說了，我專門封裝了一個消息處理的庫，服務端和客戶端使用的是庫里面同一個結構體，不可能會出現兩邊長度不一致的情況。

事出反常必有妖！

服務端是同一個服務端，因此問題只可能出現在客戶端的代碼上！因為我們的客戶端有不同版本，每個版本有單獨的代碼，而代碼只有略微差別。

我拿了不同版本的客戶端代碼進行調試，詭異的是，出問題的那個客戶端在發送消息時，結構體的長度偏偏就是280，而其他客戶端在發送消息時，結構體長度卻是288！

一個小時都過去了，我硬是沒找出問題所在，于是，我只能使用笨辦法，那就是作對比，看看出問題的客戶端代碼和沒出問題的客戶端代碼有什么不同。

這么一對比，就讓我找到了差異點，原來，出問題的客戶端代碼在編譯的時候勾選了“首選32位”，我一拍腦袋：“原來是這樣！”

這個結構體的內容很簡單，里面是由一個Int64字段+兩個Int32字段+一個指針+一個指定了長度的字符串字段組成，其中，字符串的長度被指定為255。

公司代碼是用C#編寫的，在C#中，正常情況下，Int64所占字節數為8位，Int32所占字節數為4位，指針所占字節數為8位。

而指針類型在32位環境和64位環境里面所占用的字節是不一樣的，在32位環境里占4個字節，而在64位環境里則占8個字節！

結語

因此，最終真相大白！于是我去除勾選“首選32位”，再次編譯，發現結構體的長度變成了288！

說到這里，肯定有人關心為什么項目被勾選了“首選32位”，因為我一直沒有將代碼上傳代碼庫，所以具體是怎么發生的，其實我也不知道，也許是IDE默認就給勾上了，但是因為一直沒測到這，所以問題一直沒被發現。