旧数据需要由新代码继续正确解释
区块链合约升级若要沿用已有状态，除了检查新功能，还要确认旧数据会被怎样读取。Solidity 0.8.30文档说明，持久状态按存储布局分配位置，一个槽为三十二字节；较小的值在满足规则时可以共用一个槽。变量在源码中有名称，数据的定位却依赖具体槽位和槽内偏移。
这意味着，保留了链上的数据字节，并不等于保留了正确的业务含义。新版本若把原来记录某项余额的位置解释成另一种状态，表面上仍能返回一个数，账本含义却可能已经错位。问题发生在数据与解释规则的对应关系上。
两字段账本能看清顺序变化的后果
设想一个没有部署的极简教学账本：它没有继承和自定义起始槽，只有两个uint256字段，先记余额，再记流水序号。按上述布局，二者分别占槽零和槽一。假设旧值是八十和三；新版本将声明顺序交换，却继续使用原来的数据，余额查询就可能把槽一中的三当成余额。
这里没有发生一笔把八十转成三的交易，而是新代码读了不同位置。OpenZeppelin升级文档因此要求常规布局避免重排已有变量或改变其类型。单纯改名也不会自动清空旧值。这个例子只说明两个完整槽，不能直接当作真实代币余额映射的存储图。
类型宽度和父合约也会改变位置
不能只检查字段的排列名称。Solidity文档中，值的类型宽度决定占用多少字节，能否与相邻字段打包也取决于这些宽度。即使两个版本都包含同名字段，类型调整仍可能改变偏移及后续数据位置；将其理解为给表格换一个列标题，会遗漏实际编码差异。
继承关系同样参与布局。对于普通顺序布局，父合约新增字段可能挤占原先留给子合约状态的位置，因此不能只查看最下层合约的改动。已有预留槽或命名空间方案的项目，应按照其实际约定核对边界，不能机械套用“每个文件末尾添加就安全”的规则。
新增字段与旧账本分别验证
在常规顺序布局下，OpenZeppelin文档把尾部追加作为引入新变量的基本要求；但为新增状态设置初值，仍是另一项工作。升级说明应区分哪些字段必须保持原值、哪些字段是新版本才引入，不能用重新初始化整个账本的方式代替兼容处理。
复核时可对照旧版和新版的布局输出，查看槽位、偏移、类型以及继承来源，再用旧状态样本检验读取含义。编译器版本和采用的布局约定也应一并记录，验证记录应保留预期值与实际值。位置对应检查通过，只回答状态能否按预期解释；新业务是否正确处理这些历史余额，还需要单独验证。