本文详解Solidity重入攻击的5种防御方案，包含Checks-Effects-Interactions模式、转账限制策略及OpenZeppelin合约库实战案例，提供智能合约安全开发的完整解决方案，帮助开发者构建抗重入攻击的DApp系统。
重入攻击为何成为智能合约头号威胁？
当你在编写存款合约时，是否考虑过这样的场景：用户A调用withdraw()函数提取ETH时，恶意合约通过fallback函数重复触发提现操作？这正是去年Poly Network遭遇攻击的核心漏洞。重入攻击通过嵌套调用持续消耗合约资金，就像打开了一个资金泄漏的水龙头。
防御关键点：优先处理状态变更，后执行外部调用。比如在转账前就要完成余额清零操作。检查这份防御清单是否完备：
- 是否采用CEI模式（检查→状态变更→交互）
- 是否设置函数执行锁
- 是否限制单次转账金额
- 是否使用经过审计的标准库
Checks-Effects-Interactions模式实战解析
假设我们要开发一个去中心化拍卖平台，投标退款功能是重入攻击的高危区。来看这个错误示范：
function refund() public {
uint amount = bids[msg.sender];
(bool success, ) = msg.sender.call{value: amount}("");
bids[msg.sender] = 0; // 状态变更在外部调用之后
}
漏洞所在：外部转账先于状态清零，攻击者可在回调中再次调用refund()。改进方案严格执行CEI三步走：
function safeRefund() public {
uint amount = bids[msg.sender]; // 检查
bids[msg.sender] = 0; // 状态变更
(bool success, ) = msg.sender.call{value: amount}(""); // 交互
}
转账限制策略的双重保险机制
仅靠CEI模式可能不够，我们需增加第二道防线。为借贷合约设计提现功能时，可以采用：
// 设置单笔转账上限
uint public MAX_WITHDRAW = 10 ether;
function secureWithdraw() public {
require(balances[msg.sender] <= MAX_WITHDRAW, "超出限额");
uint amount = balances[msg.sender];
balances[msg.sender] = 0;
payable(msg.sender).transfer(amount);
}
同时引入重入锁，这是OpenZeppelin的经典实现：
bool private locked;
modifier nonReentrant() {
require(!locked, "操作执行中");
locked = true;
_;
locked = false;
}
权威合约库的防御代码最佳实践
以ERC20代币合约为例，正确集成安全模块需要三步：
- 安装OpenZeppelin合约库：npm install @openzeppelin/contracts
- 继承ReentrancyGuard合约：
contract MyToken is ERC20, ReentrancyGuard
- 在关键函数添加防护修饰器：
function mint() external payable nonReentrant
智能合约安全审计的五个必检项
根据SlowMist审计报告数据，83%的重入漏洞可通过以下检查发现：
| 检查项 | 达标标准 |
|---|---|
| 外部调用顺序 | 所有状态变更必须在转账前完成 |
| 余额检查机制 | 使用balanceOf前进行require验证 |
| gas限制设置 | 转账使用transfer而非call |
FAQ：开发者最关心的重入防御问题
使用transfer就能完全安全吗？
虽然transfer限制2300gas可防止回调攻击，但部分场景仍需使用call。建议组合使用转账限制+重入锁。
如何测试防御措施有效性？
使用Foundry测试框架模拟攻击：部署恶意合约尝试递归调用，验证余额变更是否符合预期。
