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

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

代碼的業(yè)務(wù)邏輯是這樣的，我們的業(yè)務(wù)中有一個服務(wù)端和很多個客戶端，客戶端會定期給服務(wù)端發(fā)送消息，消息是以結(jié)構(gòu)體的形式發(fā)送的，當然，在發(fā)送消息的時候，需要將結(jié)構(gòu)體轉(zhuǎn)換成byte數(shù)組。

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

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

經(jīng)過調(diào)試，我發(fā)現(xiàn)所有客戶端發(fā)送的消息內(nèi)容都是一樣的，并沒有任何區(qū)別。

結(jié)構(gòu)體屬于基本數(shù)據(jù)類型，因此在定義的時候，長度就已經(jīng)確定了，我在服務(wù)端進行調(diào)試，發(fā)現(xiàn)結(jié)構(gòu)體的長度為288，但是，服務(wù)端接收到的byte數(shù)組長度卻只有280，如此一來，在將byte轉(zhuǎn)換成結(jié)構(gòu)體的時候，因為長度不一致，導(dǎo)致了轉(zhuǎn)換失敗。

前面說了，我專門封裝了一個消息處理的庫，服務(wù)端和客戶端使用的是庫里面同一個結(jié)構(gòu)體，不可能會出現(xiàn)兩邊長度不一致的情況。

事出反常必有妖！

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

我拿了不同版本的客戶端代碼進行調(diào)試，詭異的是，出問題的那個客戶端在發(fā)送消息時，結(jié)構(gòu)體的長度偏偏就是280，而其他客戶端在發(fā)送消息時，結(jié)構(gòu)體長度卻是288！

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

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

這個結(jié)構(gòu)體的內(nèi)容很簡單，里面是由一個Int64字段+兩個Int32字段+一個指針+一個指定了長度的字符串字段組成，其中，字符串的長度被指定為255。

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

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

結(jié)語

因此，最終真相大白！于是我去除勾選“首選32位”，再次編譯，發(fā)現(xiàn)結(jié)構(gòu)體的長度變成了288！

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