本文详解Solidity重入攻击的3种主流防御方案，包含交互模式优化、OpenZeppelin合约应用及Gas限制技巧，通过The DAO等真实案例演示check-effect-interact模式的实战代码，帮助开发者构建抗重入攻击的智能合约系统。
智能合约为什么总被黑客盯上？
最近Uniswap前端刚曝出钓鱼漏洞，DeFi项目累计损失已超30亿美元。开发者老张就遇到了头疼事——刚部署的质押合约被抽走200ETH。根本原因竟是重入攻击：攻击者在合约余额更新前循环调用提现函数。这种经典漏洞在2023年DApp安全报告里仍位居TOP3，60%的新项目都栽在同一个坑里。
致命漏洞代码示例：
function withdraw() public {
require(balances[msg.sender] >= 0);
msg.sender.call{value: balances[msg.sender]}(“”);
balances[msg.sender] = 0;
}
function withdraw() public {
require(balances[msg.sender] >= 0);
msg.sender.call{value: balances[msg.sender]}(“”);
balances[msg.sender] = 0;
}
OpenZeppelin的防重入神器怎么用？
现在流行用ReentrancyGuard合约，就像给函数装防盗门。通过nonReentrant修饰器，确保函数执行期间不被二次调用。来看实战配置：
- 安装OpenZeppelin库：npm install @openzeppelin/contracts
- 继承ReentrancyGuard合约
- 给敏感函数添加修饰器
正确代码模板：
import “@openzeppelin/contracts/security/ReentrancyGuard.sol”;
contract MyContract is ReentrancyGuard {
function safeWithdraw() external nonReentrant {
// 业务逻辑
}
}
import “@openzeppelin/contracts/security/ReentrancyGuard.sol”;
contract MyContract is ReentrancyGuard {
function safeWithdraw() external nonReentrant {
// 业务逻辑
}
}
Gas费能当防火墙用吗？
有开发者用gas限制法阻止攻击循环，比如将转账gas限制在2300以下。但这种方法在伦敦升级后已不可靠，ETH转账最低gas费提高到7000。更稳妥的做法是：
- 使用transfer替代call（自动限制gas）
- 余额操作前先清零
- 更新状态变量后再转账
某DEX平台就吃过亏：黑客利用gas费波动，在低gas时段突破限制完成攻击。最后还是改用ReentrancyGuard+CEI模式才彻底解决。
开发者防坑自测清单
完成合约开发后，请逐项检查：
| 检查项 | 达标标准 |
| 状态变更顺序 | 先修改余额再转账 |
| 函数修饰器 | 关键函数有nonReentrant |
| 转账方式 | 使用transfer/send |
| 单元测试 | 包含重入攻击测试用例 |
FAQ高频问题解答
Q：已用ReentrancyGuard还需要CEI模式吗？
A：双重防护更安全，特别是处理跨合约调用时。
Q：ERC721合约需要防重入吗？
A：NFT转账涉及回调函数，必须使用nonReentrant修饰器。
Q：如何测试重入攻击防御？
A：可在单元测试中部署攻击合约，模拟递归调用场景。
