重入攻击：合约尚未记账，资金就被反复提走

加密基础

2026年11月04日

重入攻击的核心问题可以用一句话说清：合约在完成自己的账本更新之前，把控制权交给了外部地址，而这个外部地址在合约"记账"之前又回头调用了同一个函数。 结果就是合约基于一份过时的、尚未扣减的余额记录，反复批准提款。以太坊官方术语表对它的定义很直接：合约调用另一个合约，后者在第一个合约完成状态更新之前回调进来，让攻击者基于陈旧数值行动。

欧易OKX交易所
全球领先的加密货币平台，适合新手与进阶交易者
新手福利：注册即享20% 交易手续费减免！

立即注册 APP下载

一个具体的资金流失过程

假设一个简化合约，功能是让用户提取自己存入的 ETH。代码逻辑可能是这样：先检查调用者的余额是否大于零，然后用 call 把 ETH 转给他，最后再把该调用者的余额清零。

问题出在"转账"和"清零"之间的那段窗口。当合约执行 call 向攻击者合约发送 ETH 时，攻击者合约的 fallback 或 receive 函数会被触发。攻击者在这段代码里再次调用原合约的提款函数。此时，原合约的余额记录还没有被清零，因为第一笔转账流程还没有走完。所以第二次调用看到的仍然是"你有 1 ETH 可提"，于是再次批准转账。攻击者可以在这个回调里循环调用，直到合约里的资金被掏空，或者 Gas 耗尽。

标题里说的"尚未记账"，指的就是这个状态：合约已经付出了资产，但它的内部账本还停留在付出之前的样子。攻击者利用的正是这个时间差。

为什么这类漏洞反复出现

以太坊上最著名的一次重入攻击是 2016 年的 The DAO 事件，约 6000 万美元等值的 ETH 被转走。The DAO 的合约在向攻击者发送 ETH 之后才去更新内部余额，攻击者通过回调反复进入提款逻辑，在余额被扣减之前完成了多次提取。如果合约遵循"先改状态、再做外部调用"的顺序，这次攻击就无法成立。

重入攻击并不只发生在远古代码里。2025 年 7 月，GMX V1 在 Arbitrum 上因跨合约重入损失约 4200 万美元；2026 年初，Futureswap 也因类似的账本更新时序问题被利用。这些案例的共同点在于：合约在与外部地址交互时，内部控制流被打断，而账本更新没有在交互之前完成。攻击面可以跨越多个合约，但触发条件仍然是同一个时序缺口。

防御的关键不是"检查有没有重入"，而是消除时序缺口

最常见的做法是调整代码顺序，让状态变更发生在外部调用之前。这就是所谓的"检查—生效—交互"模式（Checks-Effects-Interactions）：先检查条件是否满足，再更新合约内部状态（比如把用户余额扣掉），最后才执行转账或调用外部合约。按照这个顺序，即使外部合约在收到转账后回调回来，它看到的已经是扣减后的余额，无法再次提款。

另一种补充手段是重入锁（reentrancy guard）。OpenZeppelin 的 ReentrancyGuard 用一个状态变量标记"当前函数是否正在执行"，如果在执行期间被再次调用，就直接拒绝。这个方案不依赖开发者手动调整每一处代码顺序，适合给关键函数加一层通用防护。

需要注意的是，重入锁不能替代正确的代码顺序，它只是增加了一道拦截。对于复杂的跨合约交互，攻击者可能找到锁未覆盖的路径，或者利用多个合约之间的状态不同步来绕过防护。GMX 的案例就说明，四年前部署的防护机制在跨合约场景下可能失效。

作为普通用户，这个知识有什么用

你不需要审计合约代码，但可以记住一个判断原则：当一个 DeFi 合约允许你提取资金，而它的提款逻辑依赖外部调用（比如向你的地址发送 ETH 或代币）时，这个合约的代码顺序是否安全，决定了你的存款有没有被掏空的风险。你无法从界面上直接看到代码顺序，但可以看这个项目是否经过了公开的安全审计、是否使用了成熟的重入防护库、以及是否在行业内运行了足够长的时间而没有发生同类事件。这些信息不能保证安全，但能帮你排除掉那些连基础防护都没有的项目。