适用范围：通用原理不等于项目结论
讨论“杭州复杂美区块链技术需要注意哪些问题”，首先应区分企业名称与可验证的技术实现。以下内容适用于以太坊智能合约及相关访问控制设计，不能据此认定杭州复杂美的具体产品采用了这些组件，也不能推断其存在某类漏洞。
评估具体系统时，需要先确认底层链、合约执行环境、代码版本及管理方式。非以太坊环境可以参考权限分离和独立审查的思路，但不能直接套用 Solidity 语法或 OpenZeppelin 组件。
权限设计：检查谁能操作，也检查谁能授权
OpenZeppelin 访问控制文档区分单一所有者与角色权限机制，并强调最小权限原则。权限交接可以采用两步确认；默认管理员具有较高权限，需要特别保护。
实际检查应覆盖升级、暂停、参数修改等敏感操作，同时追踪谁能授予或撤销这些权限。设置多个角色不自动代表风险已经分散：若同一账户控制所有角色及其管理员，关键控制权仍可能集中。多签也需要关注签名人的独立性及密钥保管方式。
管理交接：避免权限丢失或意外失效
所有权转移不仅是更换地址，还要确认接收方能够实际控制该地址并完成必要操作。两步交接能够增加接收确认环节，但不能替代身份核验。
放弃所有权也不等于系统自动变得安全。在依赖所有者执行管理任务的设计中，放弃权限可能使相关功能无法再调用。交接前应明确后续维护责任、故障处理方式以及权限恢复是否可行。
逻辑验证：正常运行只是起点
以太坊智能合约安全文档强调访问限制、异常检查、多种测试手段和独立审查，并提醒审计不能发现所有缺陷。部署后的修复限制，使上线前验证尤其重要。
验证重点不应只有正常流程，还应包括无权限调用、异常输入和状态变化后的重复操作。输入校验与内部不变量检查承担不同职责；测试应把业务约束转化为可检验条件，而不是仅确认函数能够成功返回。
常见问题：审计和形式化验证能否保证安全
审计通过不代表永久安全。需要核对审计覆盖的代码版本、问题修复情况，以及实际部署内容是否与审查对象一致；后续变更可能引入新的风险。
形式化验证的结论受规范、模型和假设约束，不能理解为整个系统没有任何错误。具体项目是否可靠，仍需要结合实现证据和运行管理判断，不能仅凭采用某个组件或拥有审计报告下结论。