适用范围与判断依据
本文讨论采用以太坊智能合约或类似权限机制的商城方案，不涉及具体产品的实施效果。以太坊智能合约文档说明，合约按代码执行，部署与链上操作涉及费用，现实事件需要外部数据输入。OpenZeppelin访问控制文档介绍了所有者与角色权限机制，并强调管理权交接及默认管理员权限的风险。
误区一：商城功能全部上链才完整
方案应先回答哪些规则需要链上执行、哪些记录需要共同核验。商品展示、订单处理与合约规则有不同需求，不能仅凭“支持上链”决定系统边界。
对于需要链上验证的订单凭证，可以讨论其记录方式；对于频繁变化的业务内容，则应评估每次修改涉及的调用与费用。验收重点是业务规则能否完整运转，而不是合约数量或上链字段数量。
误区二：合约能自动确认发货与收货
物流、验货和退货涉及链外事实。若方案根据物流状态触发结算，就需要交代数据由谁提供、如何关联订单，以及记录冲突时如何处理。
预言机能够把外部信息送入合约，但商品质量争议仍需明确判断规则。适合自动执行的条件，应当具有清晰的数据来源和可验证的触发标准。
误区三：自动执行后就不需要售后设计
已执行的链上操作不能当作普通后台记录随意撤销。商城若需要取消订单、退款或争议处理，应在设计阶段明确允许操作的状态、执行主体和限制条件。
常见问题是“退款能否一键回滚”。业务退款通常需要另行设计操作流程，不能假定它会删除原有链上历史。评审应覆盖正常完成之外的异常路径。
误区四：一个管理员账号足够管理全部业务
单一所有者适用于管理职责简单的合约；商城存在多类运营职责时，应逐项界定权限。例如，处理某类订单的权限是否同时允许修改系统规则，需要明确区分。
角色划分之后，还要检查谁能授予或撤销角色。若所有权限最终都能由一个管理账号重新分配，仅增加角色名称并不能有效限制最高管理权。
误区五：上线后放弃权限就更安全
放弃所有权可能使依赖该权限的功能无法再调用。决定保留、转移或移除权限之前，应确认后续是否仍需执行管理操作，并验证交接对象能否接管。
多签适合需要多人共同批准的重要管理操作，但仍需明确参与者、批准条件与人员变更流程。方案验收应检查权限分配、交接和异常处理是否一致，不能把采用某个组件直接等同于系统安全。