一、先明确合约功能与适用范围
区块链合约功能需要注意哪些问题，首先取决于它能修改哪些状态、由谁调用，以及执行失败时会有什么影响。以下主要讨论以太坊智能合约及相关权限组件，不代表所有区块链平台都采用相同机制。
设计时应区分普通交互与管理操作。对每项功能，都应明确调用主体、输入条件、状态变化和失败结果，而不能只确认正常流程能够运行。
二、函数可见性不等于业务授权
公开或外部函数提供调用入口，但敏感操作仍需单独检查权限。private 限制的是函数在代码中的调用范围，不能替代完整的业务授权设计。
OpenZeppelin 的访问控制文档区分了所有者模式与角色模式：前者适合管理职责简单的场景，后者适合拆分不同权限。选择时应遵循最小权限原则，同时检查谁能授予和撤销角色，避免只限制业务入口，却忽略权限管理入口。
三、管理权交接也属于功能设计
所有权转移前，需要确认目标账户正确且能够管理合约。两步交接要求新所有者主动接受，可降低误转风险；放弃所有权则可能让依赖所有者权限的管理功能永久不可调用。
角色拆分不自动消除单点风险：如果关键角色仍由同一账户控制，风险依然集中。多签可以增加共同确认要求，但也应考虑签名方无法参与时，必要管理操作能否继续完成。
四、区分输入校验与内部不变量
以太坊安全文档强调通过条件检查阻止不符合要求的操作。require 和 revert 可用于处理输入、权限或状态条件不满足的情况；assert 更适合检查内部逻辑中本应始终成立的不变量。
功能说明应同时写清成功与失败条件。例如，参数格式正确，并不意味着当前状态允许执行。存在校验语句也不代表业务规则已经完整覆盖，关键仍是检查条件是否准确。
五、测试通过不等于安全保证
测试应覆盖正常路径、边界输入、权限拒绝和异常状态。单元测试之外，静态分析、属性测试与独立代码审查能够提供不同角度的检查。
形式化验证的结论受规格、模型和假设约束，不能理解为排除了所有现实风险。审计同样不是永久保证；功能或权限配置发生变化后，应重新评估受影响部分，并开展防御性回归验证。
六、上线前确认维护边界
已部署合约通常不能像普通服务一样直接修改代码。若系统具有升级或暂停机制，应明确谁能操作、影响哪些功能，以及权限失效时的处理边界。
最终检查不应停留在“功能是否存在”，而应确认权限是否清楚、错误是否可控、变更是否可追踪。代码版本管理、独立复核和必要文档，都是持续维护的一部分。