一、先明确智能合约是什么
关键词中的“只能合约”通常指“智能合约”。以太坊开发者文档将其介绍为部署在链上、由代码和状态组成的程序。它按照既定逻辑执行，而不是自行理解人的意图。本文讨论以太坊及相关权限组件，不将具体机制推广到所有区块链。
理解合约时，应先问它允许什么操作、满足什么条件才执行，以及执行后改变什么状态。“自动执行”只描述运行方式，不代表业务规则必然合理，也不等同于安全保证。
二、区分不可逆与可管理
已经确认的链上操作通常不能像普通应用中的编辑那样撤销。因此，设计阶段就应明确错误处置方式，不能默认事后总能修改记录。
不可逆也不意味着合约完全没有管理员。是否存在管理入口、能够调整哪些规则，应以具体实现为准。阅读说明时，要将历史操作能否撤回与未来规则能否调整分开理解。
三、权限不仅是有没有管理员
OpenZeppelin 文档区分了单一所有者和按角色授权两种模式，并强调最小权限原则。前者适合管理职责简单的情形；后者适合将不同职责分别授权。关键不仅是谁能执行操作，还包括谁能授予或撤销权限。
权限说明应能回答三个问题：日常操作由谁负责，敏感变更由谁批准，管理人员更换后如何交接。角色名称本身不能说明权力大小，需要结合其实际允许的行为理解。
四、所有权交接与多签的边界
OpenZeppelin 提供需要新所有者确认的两步交接机制；放弃所有权则可能使受所有者权限保护的功能无法再调用。因此，放弃权限不是通用的安全改进办法。
以太坊文档介绍的多签机制要求达到约定数量的有效签名，可分散单一密钥带来的风险。但多人批准不代表操作内容必然正确，签名者职责、可用性和交接安排仍需清楚。
五、外部数据和合约依赖
智能合约不能独立获取链外事实，需要借助预言机等机制引入数据。其他合约也可以成为功能依赖。自动处理数据，并不能自动保证数据真实或依赖可靠。
涉及外部信息时，应说明数据来自哪里、何时更新，以及缺失时如何处理。涉及其他合约时，应明确各自职责，避免把一个组件的可靠性当作整个系统的保证。
六、费用与常见误解
部署合约和执行改变链上状态的交易需要考虑 gas。功能设计不能只看逻辑是否完整，还应考虑执行成本和运行限制，不宜将某次费用视为长期固定标准。
常见误解是把公开代码等同于安全，把权限分散等同于没有管理权。更稳妥的理解方式，是分别检查执行规则、授权范围、外部依赖和异常处置；这些维度不能互相替代。