适用范围与技术依据
本文讨论 Java 服务接入以太坊及相关 EVM 合约的会员系统。Ethereum 开发文档介绍了 Java 交互库、节点客户端和事件监听工具；OpenZeppelin 访问控制文档说明了所有者、角色授权及管理员机制。这些技术能力可以支撑会员业务，但会员资格、权益和管理流程仍需单独设计。
误区一：用了 Java 工具就有完整会员系统
Web3j 用于与以太坊客户端交互，Besu 属于以太坊客户端，二者职责不同。能够调用合约、管理账户或监听事件，只说明接入能力已经具备。
对于会员系统，还要明确哪些行为由 Java 服务处理，哪些规则由合约执行。例如，调用会员资格相关功能时，应先确定资格由哪里记录、由谁修改，再选择对应的交互方式。工具清单不能替代业务设计。
误区二：会员等级可以直接当作管理权限
会员等级表达业务资格，管理角色表达允许执行的操作。高级会员是否享有某种权益，与该账户能否授予他人资格，是两个不同问题。
当系统存在资格发放、资格撤销和权限管理等职责时，可以按操作拆分角色。每个角色只获得完成职责所需的权限，避免因为账户具有某个会员等级，就同时赋予它后台管理能力。
误区三：后台限制入口就能保护合约
Java 服务中的权限判断只约束经过该服务的请求。对于可以直接调用的合约函数，关键操作还需在合约层校验调用者权限。
OpenZeppelin 提供单一所有者和基于角色的访问控制机制。只有一个管理主体时，所有者模式较直观；需要分工时，角色机制更合适。具有某个角色通常不代表可以授予该角色，授权能力取决于对应的管理员角色。
误区四：管理员交接只是修改一个地址
管理权限的转移会影响后续操作是否可用。两步所有权转移要求接收方确认，有助于降低错误交接的风险；放弃所有权则可能使仅限所有者调用的功能无法再执行。
设计会员系统时，应分别考虑日常业务角色和管理这些角色的权限。资格发放人员变更与最高管理权限交接，不能视为同一种操作。
常见问题：能否直接读取全部角色成员
基础 AccessControl 不提供链上角色成员枚举。需要成员列表时，可以在链下处理角色授予与撤销事件；确需链上枚举时，可考虑 AccessControlEnumerable 扩展。
角色成员列表也不自动等于完整会员名单。若角色只表示运营权限，用它统计会员就会混淆业务对象。实现查询前，需要明确查询的是会员资格、管理权限，还是授权变更记录。