适用范围：先明确账户与权限边界
讨论企业区块链项目需要注意哪些问题，应先确定技术范围。以下主要适用于采用以太坊账户模型、通过智能合约管理业务权限的系统，不能直接套用到所有联盟链或其他区块链架构。
以太坊账户文档区分了私钥控制的外部账户和代码控制的合约账户；钱包则是与账户交互的工具。OpenZeppelin访问控制文档说明，合约可以采用单一所有者或角色授权机制。两者分别回答“谁能发起操作”和“谁有权执行功能”，企业设计需要同时覆盖这两个层面。
账户安全：保管工具不等于控制权
私钥能够用于签署交易，因此企业不能只记录钱包名称和登录人员，还应明确实际签名权限由谁持有、备份由谁保管，以及人员离岗后的处置责任。更换钱包界面并不等于更换账户控制权。
合约账户没有自身的私钥，但其管理功能可能受其他账户控制。评估安全性时，需要继续追踪管理员及其授权关系，不能因为业务放在合约中，就认为已经消除了人为控制风险。
权限设计：业务操作与授权管理分开
单一所有者模式适合管理职责简单的系统；涉及多个部门或不同操作职责时，角色划分更便于限制权限。设计时可先列出业务动作，再逐项确定执行者和授权管理者，避免把所有职责集中到同一个账户。
拥有业务角色，不必然意味着能够向别人授予该角色。权限评审应分别检查操作权限和角色管理权限，尤其关注能够扩大授权范围的管理员。最小权限原则的重点是限制实际能力，而不只是增加角色名称。
管理交接：验证接收能力与失效后果
所有权转移到错误或无法操作的账户，可能影响后续管理。OpenZeppelin提供要求接收方确认的两步交接机制；放弃所有权则会使受所有者权限保护的功能不再可调用。这些操作不能简单视为普通的人事信息变更。
企业应在交接方案中核实接收账户、确认责任和异常处置路径。多签能够用于分散管理控制，但仍需明确签署人员及可用性要求，不能把采用多签本身当作完整的治理方案。
常见问题：权限变化能否持续核查
上线时检查一次权限，并不能覆盖后续的授予和撤销。审计设计应说明如何还原角色变化、核实当前授权，并将账户对应到企业内部责任人。链上地址本身不能替代组织身份管理。
另一个常见误区是认为基础权限组件天然提供完整成员名单。OpenZeppelin的基础AccessControl不支持链上角色成员枚举，可通过授权和撤销事件进行链下跟踪；确需链上枚举时，应评估相应扩展。验收时应分别验证正常调用、越权拒绝、撤权生效和管理交接，避免只确认业务流程能够运行。