部署到以太坊某个地址上的智能合约字节码，通常不能像普通软件那样直接修改，但项目方可以通过代理合约、状态迁移或外部模块，让用户继续使用同一个入口地址，却执行一套新的业务逻辑。这里最容易混淆的是代码不可变和合约不能升级并不是一回事。合约部署完成后，链上地址对应的运行时代码基本固定；合约内部的余额、参数、权限、订单和用户数据，则可能按照函数规则持续变化。能不能改，关键不在于项目方口头怎么说，而在于合约架构里是否预留了升级入口。
对普通非升级合约来说，开发者无法把原地址里的旧字节码替换成新字节码。想修复漏洞、增加功能，常见做法是重新部署一个新合约，再通过迁移脚本把用户资产或状态转前端也切换到新地址。这种方式看起来最接近不可篡改，但迁移并不轻松，用户需要重新授权，历史数据、流动性、代币余额和第三方集成也可能受到影响。至于暂停交易、修改手续费、调整预言机地址、增发代币等操作，即使能执行，也只是改变存储状态或权限参数，不能据此认定合约代码发生了变化。
币圈项目更常采用代理模式。用户与代理合约交互，代理合约通过delegatecall把调用转发给逻辑合约；升级时，项目方部署新的实现合约，再把代理保存的实现地址指向新版本，用户看到的入口地址和大部分历史状态可以保持不变。透明代理、UUPS代理和Beacon代理是较常见的设计，ERC-1967还规定了实现合约、管理员和Beacon等关键地址的标准存储槽，便于区块浏览器和安全工具识别。表面上地址没有变化，实际执行的代码已经可能换过，因此合约地址没变不等于代码永远不变。
代理升级带来灵活性，也带来新的信任风险。真正需要盯住的，是谁掌握upgrade权限，权限属于单一钱包、团队多签、DAO，还是带有延迟执行的Timelock。管理员一旦可以随时切换实现合约，理论上就可能加入资产转移、冻结余额、改变手续费甚至绕过原有规则的逻辑。升级还必须保持存储布局兼容，旧变量的顺序和位置不能随意调整，否则新逻辑可能把用户余额、授权额度或关键配置读错。检查合约时，不能只看是否已验证源码，还要查看ProxyAdmin、implementation地址、升级事件、管理员变更记录，以及是否存在时间锁和多签约束。
另一个常见误区是把selfdestruct当成删除后重部署的升级按钮。以太坊在EIP-6780之后已经限制了这一机制：对于并非在同一笔交易中创建的合约，执行selfdestruct通常不会删除代码和存储，只会转移账户余额，依靠销毁合约后复用原地址的方案不再是稳妥路径。投资者判断一个以太坊智能合约是否可改，最实用的方法是确认它究竟是不可升级合约还是代理合约，再追踪实现地址和升级权限。所谓可升级并不天然等于骗局，不可升级也不代表绝对安全，漏洞、权限后门和错误的业务逻辑，依然可能让资产面临损失。
