# 智能合约审计审什么？范围、威胁模型、工具与修复复验

整理：链小知（AI 辅助）
更新日期：2026-10-31
引用地址：https://lianxiaozhi.com/learn/smart-contract-audit-workflow

智能合约审计是在明确源码版本和部署假设下评估风险的过程，包含权限、资产流、业务约束、外部依赖与失效路径。静态检测、测试、形式化方法和人工评审各有覆盖范围；零告警、源码验证或一份旧报告都不能单独证明当前部署安全。

## 审计范围必须锁定到什么程度？

至少锁定源码仓库与提交、编译器和配置、合约列表、依赖与预期部署网络。代理实现、管理员、多签阈值、预言机和跨链组件应明确纳入或排除，不能只写一个项目名称。

例如报告审的是提交A，线上已经升级到实现B，就需另外比对差异。报告的时间、版本和排除项决定它可以支持什么结论；品牌与报告封面不能替代这组对应关系。

依据：[Ethereum：智能合约安全审查方法](https://ethereum.org/en/developers/docs/smart-contracts/security/)

## 威胁模型怎样落到检查问题？

从谁能调用、谁能改参数、谁能控制外部价格和资产怎样退出开始。逐项考虑越权、重入、精度与舍入、极端输入、依赖失效和治理变更，再检查业务不变量是否在所有路径成立。

不要只找单行代码错误。即使每个函数按预期运行，组合后的经济机制也可能失效；外部流动性、抵押品质量和管理员操作假设需要与代码结论分别记录。

依据：[Ethereum：智能合约安全审查方法](https://ethereum.org/en/developers/docs/smart-contracts/security/)
依据：[Solidity：安全边界与常见问题](https://docs.soliditylang.org/en/latest/security-considerations.html)

## 工具和人工评审怎样互相补位？

静态检测用于发现某些代码模式，单元与模糊测试探索具体执行路径，不变量测试关注持续约束，形式化方法依赖被证明的规格与假设。使用某种方法不意味着其他风险已经自动排除。

每条发现保留触发条件、影响、复现方式和修复建议。误报需要解释原因；无法复现也不能直接写成已修复。对不纳入范围的部署或链下服务，应在报告中保留边界。

依据：[Ethereum：智能合约安全审查方法](https://ethereum.org/en/developers/docs/smart-contracts/security/)
依据：[Solidity：安全边界与常见问题](https://docs.soliditylang.org/en/latest/security-considerations.html)

## 修复完成后怎样复验和阅读结论？

把问题绑定到修复提交，复现原触发路径并执行相关回归，再检查修复是否改变接口、权限或资产流。状态应区分修复并复验、接受风险、未修复与范围外，而不是统一打勾。

读者核对报告时，先找线上地址与实现、对应提交、未解决问题和后续升级。本站的Slither教程只解释检测结果，本文也不是对任何真实项目出具审计意见。

依据：[Ethereum：智能合约安全审查方法](https://ethereum.org/en/developers/docs/smart-contracts/security/)

## 继续核对
- [Slither检测工具](https://lianxiaozhi.com/tools/slither)
- [检测结果范围与分流](https://lianxiaozhi.com/tools/guides/slither-saved-detector-json-scope-triage)
- [源码验证的边界](https://lianxiaozhi.com/learn/verified-contract-boundaries)