智能合约如何防止重入攻击？Solidity开发者必须掌握的防御代码技巧

为什么重入攻击成为DeFi项目最大威胁？

当你在编写转账函数时是否考虑过这样的场景：用户调用withdraw()方法后，合约余额竟被恶意合约全部提空？2023年Poly Network漏洞事件中，攻击者正是利用未做防御的重入漏洞，在余额更新前循环调用提现函数。使用以下危险代码的合约都将面临风险：

function withdraw() public {
    uint amount = balances[msg.sender];
    (bool success, ) = msg.sender.call{value: amount}("");
    balances[msg.sender] = 0;
}

解决方案是采用「先更新后交互」原则，OpenZeppelin官方推荐将代码改为：

function withdraw() public {
    uint amount = balances[msg.sender];
    balances[msg.sender] = 0;
    (bool success, ) = msg.sender.call{value: amount}("");
}

checks-effects-interactions模式如何构建安全墙？

以太坊核心开发者提出的CEI模式，至今仍是防御重入攻击的黄金标准。国内某DEX平台最近更新的合约中，存款功能就采用这种结构：

1. 检查阶段：require(msg.value > 0, “Deposit amount error”);
2. 更新阶段：balances[msg.sender] += msg.value;
3. 交互阶段：emit Deposit(msg.sender, msg.value);

实战中可配合Mutex互斥锁加强防护，例如添加状态锁：

bool private locked;
modifier nonReentrant() {
    require(!locked, "Reentrancy detected");
    locked = true;
    _;
    locked = false;
}

Gas限制策略在防御中的特殊作用

针对transfer与send方法的Gas限制特性，新版智能合约开发规范建议：对不可信地址的交互必须使用transfer。某NFT平台在赎回功能中这样实现：

function redeem(uint tokenId) external nonReentrant {
    require(ownerOf(tokenId) == msg.sender, "Not owner");
    _burn(tokenId);
    payable(msg.sender).transfer(1 ether);
}

但当处理批量操作时，更推荐使用推拉结合模式：

• 推模式：主动转账时使用transfer
• 拉模式：用户自行提取时采用withdraw模式

防御方案实战测试指南

采用Hardhat编写测试用例是验证防御有效性的关键步骤。建议添加以下检测场景：

it("应阻止递归调用攻击", async function () {
    const Attacker = await ethers.getContractFactory("ReentrancyAttacker");
    const attacker = await Attacker.deploy(vulnerableContract.address);
    await expect(attacker.executeAttack()).to.be.revertedWith("ReentrancyGuard: reentrant call");
});

推荐的安全检测工具组合：

1. Slither静态分析工具
2. MythX智能合约扫描平台
3. Tenderly交易模拟环境