智能合约的不可篡改性保障了规则透明，但也使得错误修复与功能迭代变得困难。DApp开发引入代理合约模式，将逻辑合约与存储分离，实现可升级性。代理模式的核心是：用户始终与代理地址交互，代理通过delegatecall将调用转发给当前逻辑合约，同时将存储保留在代理中。

透明代理（Transparent Proxy）是OpenZeppelin的经典实现。代理合约包含一个升级函数，仅管理员可调用，修改存储中指向逻辑合约的地址。普通用户调用任何函数时，代理通过回退函数执行delegatecall。为避免管理员与用户函数名冲突，透明代理会检查调用者是否为管理员：若是管理员且调用函数非升级函数，则直接执行代理自身逻辑。这种模式简单可靠，但每次调用都有额外的管理员检查Gas开销。

通用可升级代理（UUPS）将升级函数放在逻辑合约中，而非代理合约。逻辑合约实现upgradeTo(address newImpl)函数，调用后更新代理中的实现地址。UUPS模式代理更轻量，但要求所有新版本的逻辑合约都必须包含正确的升级函数，否则后续升级将失败。DApp开发需在每次升级时保留upgradeTo入口，并设置权限控制。

钻石代理（EIP-2535，也称Diamond标准）支持多逻辑合约的组合。一个代理可以同时路由到多个实现合约，每个函数映射到特定实现。钻石代理适合功能极其复杂的DApp（如大型DeFi协议），允许按模块升级。但开发复杂度较高，需要管理函数选择器与实现的映射关系。

代理模式的核心难点是存储布局冲突。当逻辑合约版本升级时，新增的状态变量必须按顺序追加，不能修改已有变量的类型或顺序，否则代理中的存储数据将被错误解析。DApp开发可采用“永恒存储”模式：将所有状态存储在一个映射结构中，使用字符串键名访问，类似于键值数据库。这种方式避免了布局冲突，但Gas成本稍高。

另一种升级路径是无代理的“弃用与迁移”。部署新合约，将用户资产迁移到新地址，旧合约仅保留取款功能。这种方式无需代理，但需要用户主动操作，且流动性可能中断。适合无法承受代理复杂性的小型DApp。