审计和保险不是"二选一"，两者是不同维度的风险防御工具，不能互相替代。审计解决的是"代码有没有写错"，保险解决的是"代码写对了但逻辑本身有问题，或者部署后环境变了"，两者的覆盖范围完全不同。
审计能做什么，做不到什么
审计的本质是对合约代码进行静态分析：检查代码有没有溢出漏洞、权限漏洞、重入攻击等已知问题。但它有三个系统性盲区：
状态爆炸问题：形式化验证工具在遇到复杂的外部交互路径时，受计算资源限制只能探索有限路径，漏洞可能在工具未覆盖的路径里，而审计师同样无法穷举所有状态组合。
规范差距：审计只能验证"代码是否按规范执行"，无法验证"规范本身在经济上是否合理"。2025年底的Balancer V2漏洞中，协议经过了11次审计，但漏洞是数学运算产生的精度误差，代码完全按规范执行，只是规范本身错了。
可升级性悖论：审计是代码在某个时间点的快照。协议升级后，旧审计报告失效，而代理模式升级可能引入存储冲突风险，现有工具难以完全覆盖。
保险能做什么，做不到什么
保险覆盖审计无法覆盖的部分——主要是代码部署后的运行时风险。根据DeFiLlama数据，自2020年以来，未投保的借贷协议因攻击累计损失约77亿美元，2026年4月单月损失就超过6亿美元。
保险的核心价值在于：即使审计没发现问题，攻击发生后资金池里的钱能赔给用户。但保险也有自己的局限：
覆盖率极低：Nexus Mutual是最大的DeFi保险协议，TVL约1.235亿美元，仅占DeFi总TVL（约830亿美元）的0.14%，不到2%的DeFi资产有保险覆盖。
攻击面已转移：早期DeFi保险主要针对智能合约漏洞定价，现在多数大额损失来自私钥被盗、钓鱼、社交工程和跨链桥逻辑缺陷——这些对保险承保人来说难以定价，部分甚至不在承保范围内。
保险池本身存在循环风险：多个早期保险协议在2021至2024年间因代币经济不可持续、利益冲突等问题失败或被攻击，保险池的资本经常暴露于它原本要对冲的同一类漏洞。
两者结合才是完整的防御体系
审计是事前预防，保险是事后补偿。审计无法预测在对抗性环境中，外部预言机、流动性转移和升级依赖项之间的复杂交互；保险则能处理这些"审计无法覆盖的运行时异常"。两者是正交的深度防御组件，缺一不可。
Sherlock的模式是审计+保险捆绑——先审计，再为通过审计的协议提供保险，审计团队对审计质量承担财务风险。但即使是这种模式，也存在系统性问题：审计盲点可能同时影响多个被保障协议，导致一次关联性攻击击穿保险池，Sherlock的C+评级就反映了这种结构性风险。
常见失败原因
很多人把审计报告当成"安全认证"，认为审计过的协议就不会出问题，然后用保险覆盖全部资产。但审计是静态快照、代码会升级、攻击手法在进化——有审计的协议仍然有约30%的代码漏洞发生在审计之后，而保险池本身可能不足以应对极端系统性风险。
下一步操作
如果你要参与某个DeFi协议，先去查它最近一次审计报告的日期和审计范围（是否覆盖当前运行的版本）。然后在Nexus Mutual或Sherlock查该协议的Available Capacity和保费费率——如果承保额度低于你的持仓，要么补充其他保险，要么降低仓位。审计决定"你应不应该相信代码"，保险决定"代码出事了你怎么办"，两者需要分开评估。
