适用范围：以智能合约开发为核心
这些误区主要适用于以太坊及采用类似智能合约机制的开发委托。接单流程需要把业务需求转化为可验证的行为、权限和交付标准；仅涉及页面展示或数据查询的项目，应按实际涉及的链上功能确定安全工作范围。
误区一：功能清单明确，就能确定全部工作量
“实现某个功能”还不足以说明谁能调用、什么条件下允许执行，以及异常时如何处理。需求确认阶段应逐项明确敏感操作的授权主体和失败条件，再据此评估开发、测试及交接工作量。
ethereum.org 的智能合约安全文档强调访问控制、执行条件检查、多种测试方法和独立审查，并指出审计无法发现全部漏洞。对应接单流程，安全验证需要成为交付范围的一部分，不能只以正常操作演示作为验收依据。
误区二：后台隐藏按钮，就完成了权限控制
链上公开入口可能被绕过页面直接调用。验收权限时，应检查合约是否拒绝未授权操作，而不只是检查界面是否显示按钮。
管理账户如何分工、谁掌握升级或暂停权限，也需要在开发前确认。角色划分和多签可以服务于不同管理需求，但仍需核对各角色实际拥有的能力，避免交付后出现权限归属不清。
误区三：测试通过或完成审计，就代表绝对安全
测试结果只能支撑其覆盖范围内的结论。验收应包含无权限调用、边界输入和异常状态等情形；独立审查发现的问题，还应记录修复情况与复核结果。
常见问题是能否用审计替代开发测试。两者承担不同检查任务，应在约定中分别列明范围、责任和成果，避免把一份报告理解为对所有场景的保证。
误区四：可升级意味着上线后可以随意修改
OpenZeppelin 的升级合约文档说明，代理实例的状态初始化需要专门处理，并防止重复初始化；升级还必须保持存储布局兼容，随意改变已有变量的类型或顺序可能破坏数据。
因此，是否支持升级应在方案阶段确认。采用代理方案时，交付需说明初始化方式、升级授权和兼容性验证；新需求涉及已有状态结构时，应重新评估影响，不能直接视为普通代码修改。
误区五：部署成功就是交接完成
部署成功只说明发布环节完成。交接还应使接收方能够确认运行的是哪个版本、管理权限归谁，以及已知问题如何处理。可把源码版本、部署记录、权限说明、测试与审查结果列为验收材料，并明确后续维护和变更的责任边界。