智能合约异常处理机制怎么用？常见错误与修复方法

智能合约一旦部署上链就无法修改，这让异常处理成了开发中最关键也最容易出错的环节。很多人以为只要代码跑通就万事大吉，结果上线后遇到回滚、Gas耗尽或者逻辑漏洞，才意识到异常处理机制的重要性。简单说，智能合约的异常处理不是事后补救，而是提前在代码里埋好安全网。

合约执行到一半为什么会失败

智能合约的运行环境和普通程序完全不同。你写一个Web应用，出错了可以弹个提示框，用户刷新一下就行。但合约在链上执行，每一步都要消耗Gas，一旦中间某步出错，整个交易就会回滚，已经消耗的Gas还不退还。

最常见的失败场景是Gas不足。比如你写了一个循环，循环次数取决于外部输入，攻击者可以故意传一个很大的数，让合约在执行到一半时Gas耗尽，交易失败。另一个典型问题是外部调用失败。当你用call或delegatecall调用其他合约时，被调用的合约可能抛出异常，或者干脆不返回任何值。如果你没检查返回值，你的合约会以为调用成功了，实际上啥都没发生。

还有重入攻击，这是最经典的异常场景。攻击者在你的合约还没更新余额之前，通过回调函数再次调用你的提现函数，反复取走本该只取一次的钱。2016年的The DAO事件就是栽在这上面，几千万美元的以太坊被卷走。

用require和revert提前拦住异常

Solidity提供了require和revert两个关键字，专门用来做前置条件检查。require通常放在函数开头，检查输入参数、余额状态或者调用权限。比如提现函数里，先检查调用者是不是合约拥有者，再检查余额是否足够。如果条件不满足，require会立即回滚交易，并退还剩余Gas。

revert的作用类似，但更灵活。你可以在if语句里用revert，配合自定义错误信息，告诉调用者到底哪里出了问题。比如“余额不足”或者“已暂停交易”。这种明确的错误提示对调试和用户体验都很有帮助。

但要注意，require和revert只能处理合约内部的逻辑错误，管不了外部调用的问题。如果你调用了一个不存在的合约地址，或者调用的函数签名不匹配，require是拦不住的。这时候你需要用try/catch，这是Solidity 0.6版本引入的机制，专门捕获外部调用抛出的异常。在try块里执行外部调用，在catch块里处理失败情况，比如记录日志或者执行备用逻辑。

用检查效果交互模式防止逻辑漏洞

光靠require和revert还不够，因为异常处理不只是报错回滚，还包括防止逻辑被钻空子。业界公认的最佳实践是“检查-效果-交互”模式，简称CEI。这个模式要求你在函数里先做所有检查，再更新合约状态，最后才与外部合约交互。

拿提现函数举例：先检查调用者余额是否大于零，然后立即把余额清零，最后才发送代币。这个顺序很重要。如果你先发送代币再清零余额，攻击者可以在你发送代币的过程中通过回调函数再次调用提现，而这时余额还没清零，他就能再取一次。CEI模式通过先改状态再交互，彻底堵死了重入攻击的路。

另外，Gas限制问题也要提前考虑。如果你在合约里写了循环，最好设定一个最大循环次数，防止攻击者通过无限循环耗尽Gas。还可以用transfer和send来发送以太币，这两个函数自带2300 Gas限制，足以防止重入。但要注意，2300 Gas只够做最基本的转账操作，如果你的接收方合约需要执行复杂逻辑，可能会失败，这时候就得用call并手动检查返回值。

智能合约的异常处理不是锦上添花，而是生死攸关。每一行代码都可能成为攻击者的突破口，每一次外部调用都可能带来不可预知的风险。把异常处理机制想清楚、写扎实，你的合约才算真正能上线。