适用范围：聚焦智能合约教程
区块链应用涵盖不同技术体系，本文讨论以太坊智能合约开发与访问控制，不把相关结论直接推广到所有区块链。学习教程时，应区分展示语法的示例、验证功能的原型与承担实际业务的系统。能够编译和调用，只能说明部分流程可执行。
误区一：公开函数等于任何人都有操作权限
ethereum.org 的智能合约安全说明强调访问控制、执行条件检查、组合测试和独立审查，并指出审计不能发现所有漏洞。公开入口需要在合约内部限制敏感操作。
函数是否允许外部调用，与调用者是否获准完成操作，是两个问题。例如，管理入口可以被外部调用，但仍须验证身份。阅读教程时，应逐个核对敏感操作的授权条件，而不能仅凭函数名称或页面上是否显示按钮判断安全性。
误区二：有多个角色就没有单点风险
OpenZeppelin 的访问控制文档区分所有者模式和角色模式，并说明角色持有人与角色管理员的权限不同；默认管理员权限尤其敏感。所有权转移或放弃也会影响管理功能的可用性。
角色拆分适合需要细粒度授权的系统，但角色数量并不等于管理独立性。若同一账户掌握多个关键角色，风险仍可能集中。评估权限设计时，既要问谁能执行操作，也要问谁能授予、撤销这些权限。
误区三：复制示例即可用于实际业务
示例通常围绕某个知识点展开，不能据此推断它已覆盖业务边界。应用教程中的权限代码时，需要明确初始管理者、权限交接和撤销后的行为。放弃所有权也不是通用的安全优化：依赖所有者授权的功能可能因此无法再调用。
误区四：测试通过或审计完成就是安全证明
正常输入测试成功，不代表越权调用、异常输入和操作顺序变化都已覆盖。更有价值的问题是：哪些行为必须被拒绝，哪些状态约束必须始终成立？据此组合单元测试、模糊测试与分析工具，才能扩大检查范围。
形式化验证的结论受规格、模型和假设限制，不能等同于整个应用不存在任何错误。独立审查同样是补充检查，而不是替代设计责任的保证书。
常见问题：如何判断教程是否适合继续使用
先看教程是否交代技术版本、权限主体与使用边界，再看是否解释失败路径和测试目标。简单的单管理员场景可以采用所有者模式；需要职责分离时，再评估角色控制或多签。判断依据应是业务权限需求，而不是机制越复杂就越安全。