一、适用范围：重点是智能合约开发
区块链开发的技术有哪些常见问题，需要先明确技术层次。底层网络、应用接口与智能合约各有不同难点。这里重点讨论以太坊智能合约的权限、安全约束和维护，不把这些结论直接推广到所有区块链系统。
ethereum.org 的智能合约安全文档强调，链上代码部署后通常难以直接修改，开发阶段需要重视访问控制、状态约束和独立审查。核心问题不是功能能否运行一次，而是系统能否持续遵守既定规则。
二、函数可见性不等于业务授权
常见误区是把函数的公开可调用性与操作权限混为一谈。公开入口可以供外部账户或其他合约调用，但敏感操作仍需单独检查身份和权限；将函数声明为 private，也不等于让链上数据成为秘密。
设计时应分别回答两个问题：哪些功能允许外部交互，哪些主体有权改变关键状态。将接口设计与授权规则分开考虑，更容易看清管理职责。
三、所有者模式与角色模式如何选择
OpenZeppelin 的访问控制文档区分了单一所有者和按角色授权，并说明了所有权交接、角色管理和默认管理员的风险。两步所有权转移要求接收方确认；放弃所有权则可能使受所有者保护的管理功能无法再调用。
管理职责简单时，所有者模式便于理解；存在不同职责时，角色模式更适合表达权限边界。但角色数量增加不代表风险自动降低，还应明确谁能授予、撤销权限，以及这些管理权限最终集中在哪里。
四、异常处理不能代替业务规则设计
输入条件、调用者身份和状态要求应有清晰约束。require 通常用于检查必要条件，revert 用于明确终止不符合要求的执行，assert 则用于检查预期始终成立的内部条件。
常见问题是只添加检查语句，却没有先定义正确状态。异常回退可以阻止不符合已编码条件的状态变更，但不能发现所有遗漏的业务规则，也不能保证错误逻辑自动得到纠正。
五、部署与管理交接需要共同规划
不能照搬普通服务器软件的维护思路，假设上线后随时可以替换合约代码。若系统采用升级机制，还需单独考虑升级授权和治理边界；可升级并不意味着可以忽略发布前的质量要求。
同样，撤销管理权限不是单纯的配置清理。应先明确哪些功能依赖这些权限，以及权限移除后是否仍能完成必要维护，避免安全目标与实际运行需求相冲突。
六、审查结论不是永久安全保证
功能检查通过或完成独立代码审查，都不等于不存在缺陷。形式化验证的结论也受规格、模型和假设限制，不能脱离证明范围理解为整个系统绝对安全。
更稳妥的开发管理方式是保留版本记录、说明设计意图并安排独立复核。代码、依赖或权限结构发生变化后，应重新审视相关结论，而不是把旧版本的审查结果直接沿用到新版本。