适用范围与基本概念
本文讨论以太坊智能合约访问控制及其配套查询接口，不把“授权”泛指所有钱包签名或代币额度批准。OpenZeppelin访问控制文档解释谁能执行合约操作；以太坊JSON-RPC文档解释应用如何与节点交互。两者分别对应权限规则与通信机制，不能互相替代。
误区一：接口能访问，就代表操作有权限
JSON-RPC提供读取链上数据和提交交易的方法，本身不等同于业务授权。应用能够连接节点，并不意味着调用账户具备合约管理权限。
因此，前端隐藏按钮或服务端限制入口只能管理自身访问路径。设计审查还应追问：绕过该入口直接调用合约时，敏感操作是否仍受权限检查约束？
误区二：所有管理功能都交给同一账户
Ownable适合单一管理者场景；职责需要分离时，AccessControl可按角色限制操作。选择依据应是权限边界，而非接口数量。
例如，负责某项日常操作的账户是否也需要改变其他人的权限？若答案是否定的，就应分别描述执行权限和管理权限，避免为了实现方便而扩大授权范围。
误区三：拥有角色，就能分配该角色
在AccessControl中，持有业务角色并不自动获得授予或撤销该角色的能力，这由对应管理员角色决定。默认管理员角色还默认管理自身，不能按普通业务角色对待。
授权接口设计应把“谁可执行”“谁可授予”“谁可撤销”列为不同问题，并检查初始配置。仅部署受保护函数，却没有规划权限分配与回收路径，可能使后续管理无法完成。
误区四：交接与放弃权限只是普通配置变更
Ownable2Step要求新所有者接受交接；放弃所有权则会使仅限所有者的功能无法继续调用。两类操作的后果不同，不宜包装成含义模糊的统一按钮。
交接前需要确认接收方能够承担管理职责；放弃前需要梳理仍依赖该权限的功能。操作不可再执行，未必等于系统不再需要该操作。
误区五：查询成功就是授权生效
以太坊状态查询可指定区块，latest、pending和finalized表达不同的状态视角。JSON-RPC还区分数值与字节数据的十六进制编码，不能只因它们都是字符串就采用相同校验方式。
常见问题是“为什么页面显示有权限，实际调用却失败”。排查时应核对网络、合约、账户及查询区块，并区分查询结果与实际执行结果。权限界面展示的是某个状态下的判断，不是对后续调用必然成功的承诺。