可升级合约：代理模式与存储槽
2026/8/24大约 2 分钟
Web3 区块链系列 · 阶段 4 · 代币标准 · 第 26/57 篇 · 🚧 占位待学
上一篇：《ERC-4626 金库标准与通胀攻击》
下一篇：《合约工程模式：工厂、多签与时间锁》
学习大纲：《Web3 区块链学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.4
一、本文要解决的问题
合约部署后不可改，发现 bug 怎么办？「代理合约」让逻辑可换、存储不变——这是把 Web2 的迭代习惯搬进 Web3 的唯一通道，也是存储槽碰撞事故的高发区。
二、知识点清单
- 不可变性问题与代理思路：用户永远调代理，代理 delegatecall 到实现合约
- delegatecall vs call：在谁的存储上跑谁的代码（阶段 2 存储布局的回扣）
- 三种代理：EIP-1967（标准槽位）/ Transparent（管理员歧义处理）/ UUPS（升级逻辑在实现里）
- 存储槽碰撞：变量顺序错位导致数据张冠李戴的灾难
- 初始化问题：initializer 修饰器 vs constructor（实现合约的 constructor 不会跑在代理上）
- 升级权限治理：谁能升级（为多签/时间锁埋钩子）
三、动手实验（学习时必须真跑）
- 部署 V1 → 升级 V2 的合约，验证存储数据原样保留
- 故意构造一次存储槽错位（V2 变量顺序改乱），观察数据错乱现场
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（以太坊 Fusaka / Solidity 0.8.36 / Foundry v1.0 / OpenZeppelin Contracts 5.x）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。