一、先明确合约的适用范围
关键词中的“只能合约”通常应为“智能合约”。本文讨论以太坊智能合约及 OpenZeppelin 权限组件涉及的安全问题，不直接推广到所有区块链系统。
以太坊智能合约安全文档强调，链上代码部署后通常难以直接修改，独立审查也不能保证发现全部缺陷。因此，不能把“能够正常执行”或“已经审计”理解为绝对安全；设计阶段就应考虑权限、约束和后续维护。
二、区分公开入口与操作权限
函数可以被外部调用，不代表调用者应当拥有管理权。面向公众的普通功能与涉及系统配置的敏感功能，应当采用不同的授权要求。
判断权限设计是否清楚，可以先回答三个问题：谁可以操作、可以操作什么、谁有权改变这些权限。若这些职责没有明确区分，仅仅设置一个管理员名称并不足以说明管理边界。
三、按职责选择管理方式
OpenZeppelin 的 Ownable 适合单一管理主体；AccessControl 支持按角色分配职责。角色持有者与角色管理员不是同一概念，默认管理员尤其需要谨慎配置。两步所有权交接要求新所有者确认接收，而放弃所有权可能使受限管理功能无法再调用。
选择机制应以实际职责为依据，而不是越复杂越好。业务角色虽然分开，但若最终都由同一个账户控制，就不能仅凭角色数量认定已经分散管理风险。
四、明确异常处理的职责
以太坊安全文档介绍了输入与状态检查、内部不变量检查以及异常回退等保护措施。它们用于约束执行条件，但不能代替完整的业务规则。
例如，权限正确与业务条件成立是两个不同问题。设计说明应分别交代操作资格、执行前提及失败时的处理方式，避免只关注正常流程而遗漏必要约束。
五、提前安排交接与持续维护
管理方案不仅要说明最初由谁负责，也应覆盖人员变动后的权限撤销与交接。对于需要长期维护的系统，放弃管理能力并不必然比保留受约束的管理能力更合适。
审查时应把代码与权限说明一起考虑：实际配置是否符合职责划分，管理能力是否仍满足维护需要。安全更适合作为持续管理要求，而不是一次审查后永久成立的标签。