想象一下，你正在写一个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合约时出现问题，并且只有在修改初始成员后才重新部署后者。
只是不要忘记，如果你真的想在合约中使用枚举，最好三思而后行。