讨论范围：以智能合约研发为重点
精通区块链研发技术有哪些常见问题，可以先从合约能否正确限制操作、处理异常和验证行为入手。以下聚焦以太坊智能合约安全与权限设计，不涵盖共识算法、节点实现等全部区块链研发领域。掌握语言语法只是基础，还需要说明每项敏感操作由谁执行、受哪些条件约束，以及失败时如何处理。
公开函数是否意味着任何人都能操作
函数可被外部调用，与调用者有权执行敏感操作是两个层面。以太坊开发者安全文档强调访问控制和执行条件检查；研发时应把权限要求落实到合约中，不能仅靠前端隐藏按钮。
例如，审查一个管理入口时，需要分别确认调用者身份是否符合要求、输入是否有效、当前状态是否允许操作。只检查其中一项，无法证明整个操作符合业务规则。
单一所有者与角色权限如何选择
OpenZeppelin 的访问控制文档区分了单一所有者管理与按角色授权：管理职责简单时可以采用 Ownable，需要细分职责时可以使用 AccessControl。持有业务角色不等于能够分配该角色，角色管理员需要单独设计。
常见误区是角色名称分得很细，却把所有权限集中到同一账户。评估权限结构时，应同时检查业务操作权限和授权权限。多签可以提高敏感操作的批准门槛，但效果仍取决于签名者安排与密钥管理。
权限交接为何也是研发问题
权限设计还要覆盖人员更换和管理职责移交。Ownable2Step 要求新所有者主动接受交接，可降低地址填写错误造成的风险；放弃所有权则会使受 onlyOwner 保护的功能无法再被调用。
因此，交接测试不能只验证旧账户失去权限，还应验证新账户能够执行必要操作。对于仍需维护的功能，应先弄清放弃权限后的影响。
异常检查和测试分别解决什么问题
require 通常用于检查输入、授权和执行条件，assert 用于检查内部应始终成立的不变量，revert 可在特定分支主动终止执行。这些机制的有效性取决于条件是否写对，不能自动补全遗漏的业务约束。
测试也需要围绕约束展开：除了正常调用，还应覆盖未授权调用、边界输入和不同操作顺序。静态分析、模糊测试可以补充单元测试；形式化验证的结论受规格、模型及假设范围限制。
通过审计是否代表研发完成
以太坊安全文档将独立审查视为补充保障，审计并不能发现所有缺陷。研发团队需要保留清晰的设计说明、版本记录和变更审查，让审查者能够理解预期行为。后续若修改权限或业务逻辑，也应重新检查原有测试与安全结论是否仍然适用。