想象一下，你正在寫一個Solidity智能合約，其中一個屬性可以被描述為類型或狀態。換句話說，來自一組有限的選項。你馬上對自己說：“太好了，我只會使用枚舉類型來表示這個狀態變量。”一方面，這種方法有一些好處，比如增加可讀性。另一方面，它很容易讓你走上一條可能導致問題的棘手道路。

好吧，如果枚舉（ENUM）成員僅封裝在一個合約中并且從未在其他文件中提及過，那么一切都可以。 然而DAPP通常由幾個相互連接的合約組成。當相同的枚舉（ENUM）出現時，我要討論的問題會出現：

1. 枚舉成員出現在多個合約中

2. 在DApp生命周期中進行修改

例如您有2份合約。第一個是存儲非常重要的信息。您還聲明了一個帶有枚舉定義的接口以引用它。

contract IStorage {

enum RecordState {StateA， StateB}

function setState（address user， RecordState newState） public;

}

contract Storage is IStorage {

mapping（address=》RecordState） public states;

constructor（） public {}

function setState（address user， RecordState newState） public {

states［user］ = newState;

}

}

每個用戶的記錄都用一個包含兩個可能選項的枚舉來表示：statea和stateb。setState函數可以更改用戶的狀態。還有另一個合約，終端用戶應該與之交互（為了簡單起見，我在存儲合約中省略了訪問控制修改器）。

contract StorageUser {

IStorage public recordStorage;

constructor（IStorage _recordStorage） public {

recordStorage = _recordStorage;

}

function changeStateA（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateA）;

}

function changeStateB（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateB）;

}

}

然后將這些合同部署到區塊鏈。

一切都很好：你調用changeStateA或changeStateB，并通過自己的setState函數相應地修改存儲合約的數據。 但是有一天你意識到你需要一個全新的狀態選項來實現一些全新的功能。你稱之為Statec（哇！多好的名字啊！）。首先，通過在IStorage中添加新的枚舉成員來修改源代碼…

enum RecordState {StateA， StateB， StateC}

和StorageUser的新方法。

function changeStateC（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateC）;

}

此外，作為一個負責任的開發人員，您編寫調用新方法的測試并報告成功。您的計劃是僅重新部署StorageUser合同，并且您不希望重新部署存儲，因此很多重要數據都采用映射形式，很難遷移。因此，StorageUser將使用當前存儲作為其構造函數參數進行重新部署。你調用新的changeStateC函數。..。..它失敗了。

失敗的根源

你看，更新后的StorageUser知道RecordState枚舉的3個成員，但舊的Storage沒有關于新的StateC選項的線索。它無法將setState函數參數StateC轉換為其枚舉版本，因此失敗。

更重要的是，您的測試可能會欺騙您，因為他們使用了兩個合約的更新版本。

實際上，你甚至可以在官方文件中看到關于這個問題的警告。從整數顯式轉換在運行時檢查該值是否在枚舉范圍內，否則將導致失敗的斷言。

要吸取的教訓

首先，在如上所述的情況下，用普通整數替換枚舉更好。是的，它們看起來不那么好但結果結構更可靠和可擴展。

其次，不要拋棄使用枚舉字段的整個想法。 如果這樣的領域只在一個合約內，那絕對是安全的。 如果您可以確保在修改的情況下完全重新部署使用枚舉的所有合約，這也是安全的。 請記住，當枚舉首次從IStorage導入到StorageUser合約時出現問題，并且只有在修改初始成員后才重新部署后者。

只是不要忘記，如果你真的想在合約中使用枚舉，最好三思而后行。
來源；區塊鏈研究實驗室?