一、把难以篡改当作数据必然真实
NIST《区块链技术概述》将区块链描述为分布式实现、能够显露篡改并抵抗篡改的数字账本，并将记录发布后不被更改的表述限定在网络正常运行的条件下。这不等于任何条件下都绝对不可修改。
实践中需要区分两个问题：记录是否被改动，以及记录最初是否真实。例如，把一项业务声明写入账本，并不能仅凭上链证明声明符合现实。涉及链外信息时，仍需明确数据来源和核验责任。
二、把分布式部署当作权限自然分散
账本由多个节点维护，不代表业务管理权也由多方共同控制。评估方案时，应分别考察记录如何维护、敏感操作由谁批准，不能只用节点数量判断管理风险。
以太坊智能合约安全文档强调访问控制、多签管理及多种验证方式，也提醒审计不能发现所有漏洞。由此可见，底层网络的运行机制不能替代应用自身的安全设计。
三、把函数可见性当作业务授权
允许外部调用一个函数，与允许任何人执行其中的敏感操作，是不同的设计决定。涉及管理动作时，需要核对调用者身份和权限，而不是仅确认函数能否正常执行。
角色分工适合权限职责不同的场景，多签适合需要共同批准的操作；两者都不能自动消除风险。关键问题是权限是否过大、管理账户失陷会影响什么，以及相关人员是否真正独立。
四、把测试通过当作没有漏洞
正常输入下运行成功，只能说明已测试的路径符合预期。对于智能合约，还应关注异常输入、越权调用和不同操作顺序是否破坏预期约束。
单元测试、模糊测试、静态分析和独立审查回答的问题不同，适合互相补充。形式化验证的结论也受所写规范、模型及假设限制，不能扩展为整个系统在所有现实条件下都安全。
五、把部署完成当作实践结束
智能合约部署后的修复方式受到其架构限制，因此不能默认可以像普通服务一样直接替换代码。适用方法应在部署前明确：是否支持升级、谁有权升级，以及相关权限会引入哪些信任要求。
常见问题是“完成审计后还需要验证吗”。答案是需要：代码修改、权限配置和外部依赖都可能影响安全边界。审计应被理解为某一范围内的检查，而不是永久有效的安全证明。