适用范围：重点是智能合约审计
讨论“国外分析区块链审计有哪些常见问题”，需要先区分审计对象。这里聚焦智能合约代码及权限设计，不涉及财务审计，也不代表对所有国外审计机构的统计结论。Ethereum.org 的智能合约安全文档强调测试与独立审查相互补充；OpenZeppelin 的访问控制文档则说明所有权、角色管理及权限交接的风险。
问题一：公开函数是否缺少授权检查
函数能够被外部调用，不等于任何调用者都应被允许执行敏感操作。审查铸造、暂停或管理功能时，需要区分“入口可见”与“操作获准”。关键问题是：哪些账户可以改变关键状态，未授权调用是否会被拒绝，权限检查是否覆盖全部相关入口。
问题二：分配角色后是否仍有集中风险
OpenZeppelin 文档指出，角色管理员能够授予或撤销相应角色，默认管理员尤其需要谨慎管理。所有权转移到错误账户可能妨碍管理操作，放弃所有权则会使仅限所有者的功能无法再被调用。两步交接提供由新所有者确认的机制。
因此，审计不能只看角色名称是否齐全，还要追问谁能重新分配权限。如果多个角色最终受同一账户控制，职责划分并不自动等于风险分散。多签可以增加授权门槛，但不能代替对权限结构本身的检查。
问题三：异常检查与测试是否覆盖边界
Ethereum.org 文档介绍了输入检查、异常回退、单元测试、静态分析、模糊测试和形式化验证等方法，并提醒独立审计无法找出所有缺陷。
检查重点不只是正常调用能否成功，还包括无效输入、权限不足和异常状态能否正确失败，以及关键约束是否始终成立。单元测试通过只说明已编写的测试用例通过；形式化验证的结论也受所选规范、模型与假设约束，不能扩展成整个系统绝对安全。
问题四：是否把一次审计当成长期保证
阅读审计结论时，应区分审查范围内的代码问题与范围外的运行风险。审计过某一版本，不意味着后续修改天然受到同样覆盖；发现问题，也不等于修复已经得到确认。
更合理的理解是把审计作为开发质量控制的一环：明确预期行为，开展测试和独立复核，对修改继续审查。判断报告价值，应关注检查了什么、结论依赖什么条件，而不是仅凭“已审计”三个字判断安全性。