代理合约的三层结构：地址、逻辑、数据各归各位是怎么做到的

链上代码天生不能改，怎么办

以太坊上部署的合约字节码一旦上链就不再变化，这是确定性验证的基本要求。但业务会出 bug、会迭代，直接重部署的代价是让所有用户改地址、重新授权，几乎不可接受。代理合约模式给出了工程解法：把三个关注点拆成三层。第一层是代理合约，占据用户记住的地址，几乎不存业务数据，任务只有一个——把收到的调用转发出去；第二层是实现合约，装着真正的业务字节码，可以随时替换成新地址上的新版本；第三层是存储，因为转发用的 DELEGATECALL 以代理合约的身份执行实现代码，所有读写都落在代理合约名下，数据天然与逻辑分离。换实现，就是换一件外套，仓库里的货一件不用搬。

三种转发路线

历史上进化出三种代理形态。朴素代理要求为对外暴露的每个函数手写一遍转发代码，接口一多字节码就膨胀，而且接口一旦变化，代理和实现要一起重发。通用代理用回退函数接收一切未匹配的调用，统一用 DELEGATECALL 转发原始调用数据，任何接口都能透传，代价是每次调用的 Gas 稍高、调试时需要额外解释器支持。最小代理（EIP-1167 一类）把实现地址直接烧死在极短的字节码里，调用最省 Gas，但完全不可升级，更像是省 Gas 工具而非升级方案。读合约的人看到一小段字节码里有连续两个地址出现在固定位置，基本就能认出这是代理壳子。

存储插槽的君子协定

代理架构最大的暗坑是变量撞车：实现合约按顺序从零号槽位起使用存储，而代理合约自己也用了前面的槽位，一旦两边撞上，用户的余额可能和代理的管理员变量共用同一条格子。ERC-1967 为此定下两个著名的槽位约定——实现地址和管理者地址分别存放在用公式从固定字符串哈希出的超级大数槽位上，几乎不可能与业务变量的自然排布相撞。审计时只要用这两个哈希槽去查代理合约的存储，就能直接读出它当前的实现与升级权归属。Solidity 后来提供的 ERC-7201 命名空间思路，本质是同一问题的一般化答案。

用户该看什么

对普通用户，代理结构意味着一个必须正视的事实：你交互的合约规则可能随时被改。可查的信号有三个。看权限：读 1967 管理者槽位，地址若是多签或时间锁，改规则需要多人合作或等待；若是某个外部账户，单把私钥就决定合约未来。看实现是否验证：实现地址在浏览器有源码，才能读懂它现在的行为。看模式声明：项目是否写明使用透明代理还是 UUPS，两者的升级函数入口不同，误判会导致把 UUPS 合约当成有独立管理员的透明代理。这三项都不合格时，应当把该合约视为逻辑可被单方改写的地址。

快速问答

问：怎么一眼区分代理还是普通合约？ 答：看字节码是否极短且含 DELEGATECALL 或固定跳转模式，再查 1967 槽位是否有值；槽位指向的已验证合约才是它真正的逻辑。

问：代理合约会拖慢交易吗？ 答：多一层转发，每次调用大约多几千 Gas，通常可忽略。

问：没有代理的合约就一定安全吗？ 答：恰恰相反，不可升级意味着漏洞永远在，两种模式的风险形态不同。

常见误区

一是把有代理等同于项目负责地维护，权限集中的代理比不可升级合约更危险；二是忽略实现合约也可以自带后门，代理只是转发，实现代码的质量才是本体；三是以为换实现会丢数据，只要存储布局兼容设计得当，数据留在代理地址里不动。

风险提示：本文为合约架构科普，不构成任何投资建议；与可升级合约交互前请核实升级权限与当前实现代码。