一、权限集中与职责边界不清
以太坊智能合约安全文档强调访问控制、操作条件检查和独立审查。公开可调用不等于允许任何人执行敏感操作；角色划分和多签管理能够降低部分管理风险，但不能代替完整的权限设计。
架构上的常见问题，是把业务管理、升级和暂停能力全部交给同一个账户。需要长期维护的系统，应明确各项权限的持有人、授权范围与交接规则。增加管理员数量并不自动带来安全，关键是避免不必要的权限重叠和共同失效。
二、把代理部署误认为自动具备升级能力
OpenZeppelin代理文档区分了透明代理、UUPS和信标模式：升级职责可能位于代理、实现合约或信标中，ERC1967Proxy本身并不自动提供完整升级机制。选择模式时，必须同时明确升级入口及其授权边界。
代理适合确有持续维护需求的系统，但会引入额外治理责任。架构评审不能只问“能否升级”，还要问“谁能批准、哪些实例受影响、升级能力是否持续保留”。无需升级的场景，不应仅因模式流行就增加复杂度。
三、忽略存储兼容和初始化生命周期
在委托执行的代理架构中，替换业务逻辑不意味着原有状态会自动适配新逻辑。升级前需要审查存储布局兼容性；使用标准化代理存储槽，也不等于业务变量之间的兼容问题已经解决。
初始化同样属于架构责任，而非部署脚本的附属步骤。应明确初始化时机、执行权限以及完成状态的确认方式。采用工厂或克隆模式时，还应检查实现地址和部署配置，不能把交易成功简单等同于业务初始化完成。
四、共享实现扩大变更影响范围
信标模式适用于多个实例需要统一维护的情况，但集中更新也意味着变更影响范围更大。共享机制减少重复管理工作，并不会消除各实例状态和使用条件之间的差异。
设计时应记录实例与实现之间的依赖关系，明确统一升级的适用范围。选择架构不能只比较部署成本，还应考虑维护责任、变更审查成本以及局部问题对整体服务的影响。
五、把校验、审计或形式化验证当成保证
输入检查、权限判断与内部不变量检查承担不同职责。架构应先定义允许的状态和操作，再安排对应约束，而不是依赖零散的检查语句补齐业务规则。
独立代码审查能够增加发现问题的机会，但不保证没有缺陷。形式化验证的结论也受规格、模型和假设约束，不能扩大解释为整个系统绝对安全。版本管理、变更复核和清晰文档，仍是持续维护的基础。
六、适用范围与判断原则
上述问题主要针对以太坊及采用类似EVM代理机制的合约。其他区块链的执行和升级模型可能不同，不宜直接套用。评估架构时，应优先确认权限是否必要、状态是否兼容、依赖是否清楚，以及维护流程能否覆盖整个生命周期，而不是只关注采用了哪一种设计模式。