适用范围：聚焦智能合约安全审计
这里的区块链审计，主要指对智能合约代码、设计及权限机制的安全检查，不涉及财务审计或合规认证。以太坊安全文档强调，独立审查是安全开发的补充；OpenZeppelin访问控制文档则说明了所有者与角色权限的具体机制。两者分别帮助理解审计的能力边界和权限检查对象。
误区一：有审计报告就代表没有漏洞
审计无法保证发现所有缺陷。理解报告时，需要区分检查了什么、发现了什么，以及哪些问题已完成修复。某个版本接受过审查，不意味着之后的修改也得到同样验证，更不能把合约审查结论扩大为整个应用的安全保证。
误区二：测试通过即可替代审计
正常输入下功能可用，不等于异常输入或特殊调用顺序下仍然安全。单元测试、静态分析、模糊测试与独立审查各有作用，应围绕不同风险互相补充。形式化验证同样有边界：证明针对的是指定模型和安全属性，而非所有现实条件下的绝对安全。
误区三：引入权限组件就完成了权限安全
OpenZeppelin的Ownable提供单一所有者机制，AccessControl支持角色授权，但组件不会自动判断业务权限是否合理。DEFAULT_ADMIN_ROLE默认可管理其他角色，也能管理自身，因此管理员账户仍是关键风险点。
审查不能只看是否写了权限修饰符，还要追问谁能授予权限、谁能撤销权限，以及敏感操作是否遗漏检查。多个角色若最终受同一账户控制，也不能仅凭角色数量认定风险已分散。
误区四：多签或放弃所有权能解决所有问题
多签能提高敏感操作的授权门槛，却不能修复合约逻辑错误；角色分工也需要结合实际控制关系判断。放弃所有权则会使依赖onlyOwner的功能无法再调用，可能同时失去必要的维护能力。这些机制是否适用，取决于应用需要保留哪些管理功能，而不是机制名称是否显得更安全。
常见问题：发现漏洞后，审计就结束了吗
发现问题只是起点，还需要检查修复是否针对根因、是否影响其他功能，并通过回归测试和复查确认结果。代码变更后，应重新评估受影响范围。漏洞赏金可以增加外部发现问题的机会，但不能替代开发团队的代码质量责任。审计更适合作为持续安全流程的一环，而非上线前的一次性盖章。