一、部署前明确安全边界
以太坊智能合约需要把安全检查前置到设计和开发阶段。ethereum.org 的智能合约安全文档指出，部署后的代码通常难以直接修改，安全缺陷造成的损失也可能难以挽回。文档强调访问控制、运行条件检查、多种测试方法和独立审查的配合。
设计时可以先明确三个问题：合约控制什么资产或数据，哪些操作会改变关键状态，以及谁有权执行这些操作。这样才能把业务要求转化为可检查的权限规则和测试目标。
二、敏感功能与管理权限分别审视
OpenZeppelin 的访问控制文档区分了单一所有者与角色授权，并强调最小权限原则。所有权可通过两步流程转交；放弃所有权会使受所有者限制的功能无法再调用。默认管理员通常能管理其他角色，因此自身也需要严格保护。
只有单一管理职责时，所有者模式较直观；涉及多种职责时，角色划分更便于限制各账户的能力。但拆分角色并不自动消除单点风险：如果同一账户仍能授予全部权限，关键控制权依然集中。
常见问题是把公开函数等同于无条件开放操作。函数可以允许外部调用，同时在执行敏感逻辑前检查调用者权限。审查时既要检查业务函数，也要检查谁能授予、撤销或转移权限。
三、条件检查需要对应业务规则
输入是否合法、当前状态是否允许操作、执行结果是否保持核心约束，是不同层次的问题。require 通常用于验证前置条件，revert 用于显式拒绝执行，assert 用于检查内部不变量。
例如，权限检查通过并不代表输入和状态一定合理。检查规则需要相互补充；回滚只能阻止已经被规则识别的问题，遗漏的业务约束仍可能留下缺陷。
四、测试与审查各有适用范围
单元测试适合验证明确场景，还需要考虑未授权调用、边界输入和连续操作。模糊测试与静态分析可扩大检查范围；形式化验证则针对明确的规格和假设证明特定性质，其结论受模型与规格范围限制。
独立审计提供额外审查视角，但不能保证发现所有漏洞。理解审计结论时，应关注审查覆盖了哪些代码、发现的问题是否修复，以及修改后的代码是否得到复核。
五、权限交接也是安全问题
多签适用于需要多人共同批准的重要管理操作，但仍取决于签名门槛和参与者的密钥管理。所有权转移、角色撤销和管理权限放弃，都应先确认对后续维护的影响。
尤其需要区分“减少权限”与“失去必要维护能力”：永久关闭某项管理功能是否合理，取决于合约是否仍依赖该功能完成后续操作。