准备上线智能合约时，先别急着把源码交给审计方：范围没定、部署配置缺失，或关键假设未写清，都可能让问题留在检查范围之外。有效的web3安全审计不只是找代码漏洞，还要核对合约如何被调用、谁能改变状态，以及修复是否真正进入待部署版本。
1. 审计范围和代码版本不一致
风险常从边界开始：只提交核心合约，却遗漏代币、代理合约、初始化逻辑或部署脚本，审查结论就无法覆盖完整调用链。源码分支、编译器版本、依赖库和实际部署字节码若不一致，报告也可能对应错误版本。
交付前固定代码提交版本，列出纳入与排除的合约、依赖版本、编译参数和部署地址；若使用代理模式，还要说明代理、实现合约及初始化流程。OpenZeppelin Contracts等依赖应标明具体版本，不能只写库名。
2. 权限控制过宽或初始化不严
逐项检查铸币、暂停、升级、提取资产等敏感操作：调用者是谁，权限由何处授予，是否存在撤销或转移机制。重点核对构造函数和初始化函数，代理合约中的初始化通常需要防止重复执行；管理员权限若集中在单一密钥，也要评估丢失或泄露后的影响。
3. 外部调用引发重入或状态错乱
合约向其他合约转账、调用代币接口或执行回调时，对方代码可能在当前操作完成前再次进入本合约。检查余额更新与外部调用的先后顺序，并确认相关函数是否可重入。2016年The DAO事件是重入风险的知名历史案例，但不能据此假定所有外部调用都会被利用；应结合具体调用路径验证。
4. 对代币行为和数值边界想当然
不同代币实现可能在转账返回值、精度和转账金额上存在差异。若业务按请求金额记账，却未核对实际到账金额，可能产生账面余额偏差。还需检查零值、极大数、舍入、手续费及精度换算，确认每种输入下余额变化符合预期。
5. 预言机与经济假设未纳入威胁模型
依赖链上价格、抵押率或清算阈值的合约，不仅要检查取价代码，也要说明价格来源、更新条件和异常时的处理。预言机风险包括价格过期、市场流动性不足和短时价格偏移。测试时覆盖价格缺失、突变和边界值，并确认暂停或限额机制不会制造新的资金锁定问题。
6. 升级、部署和修复缺少闭环
安全结论取决于最终上线内容。升级可能引入存储布局冲突，部署参数错误也可能让正确代码处于错误配置。审计发现修复后，应确认修改进入目标版本，并重新检查相关调用路径；未修复项需记录影响、原因和接受风险的责任方。
审计前的可执行准备流程
锁定代码提交，整理合约清单、依赖版本、编译设置和部署方案。
画出资金流与权限流，标注外部调用、管理员操作、升级入口和价格依赖。
提供测试、预期行为及已知限制；可用Slither做静态分析、用Echidna进行属性模糊测试，作为审计补充而非替代。
逐条处理审计发现，记录修复提交，并对最终候选版本复测部署配置。
归根结底，web3安全审计要覆盖代码、权限、依赖和上线过程。把边界与假设提前讲清，再对最终版本完成修复复测，才能让报告更贴近真实风险；审计仍不能保证系统绝无漏洞。
常见问题
审计报告能保证合约安全吗？
不能。报告反映特定范围和版本的检查结果，后续改动、依赖变化或未纳入范围的组件都可能带来新风险。
静态分析可以代替人工审计吗？
不可以。工具适合发现部分模式和辅助测试，但业务逻辑、权限边界及经济假设仍需结合上下文审查。
代码还会修改，能先做web3安全审计吗？
可以先审查相对稳定的版本，但必须记录版本差异；涉及安全逻辑的修改应重新评估，不能直接沿用旧结论。
审计前最重要的材料是什么？
至少准备固定版本源码、依赖与编译信息、部署配置、权限说明、关键业务假设及可复现测试。