什么是重入攻击
重入攻击（Reentrancy Attack）是智能合约领域最经典、破坏力最强的漏洞类型之一。简单来说，当一个合约在完成自身状态更新之前就向外部地址转账或发起调用，而外部地址恰好是攻击者控制的恶意合约时，攻击者可以在原函数尚未结束的情况下「重新进入」该函数，反复执行未完成的逻辑，从而多次提取本不该属于自己的资产。
本文以官方解释重入攻击的视角，梳理其机制、流程与防护。要深入理解底层细节，建议同时参阅 Solidity安全官方文档 与 OpenZeppelin官方文档 中关于安全模式的章节。
机制原理：调用顺序与状态时机
重入漏洞的根源在于「先交互、后记账」的错误顺序。一个存在漏洞的取款函数通常这样工作：先检查用户余额，再向用户地址转账，最后才把余额清零。问题在于，转账这一步会触发外部地址的回调（在以太坊上即 fallback 或 receive 函数）。
如果接收方是恶意合约，它可以在收到转账的回调里再次调用取款函数。由于此时余额尚未被清零，检查依然通过，于是攻击者得以二次、三次乃至多次提款。理解这一点需要对 以太坊节点官方文档 描述的交易执行模型以及 Solidity安全官方文档 中的调用语义有清晰认识。
值得强调的是，重入并不局限于同一函数，还存在跨函数重入与只读重入等变体。攻击面之广，使得它常常出现在 闪电贷官方文档 所描述的复合攻击中，攻击者借助瞬时大额资金放大重入造成的损失。
典型攻击流程拆解
一次完整的重入攻击通常包含以下步骤。第一步，攻击者部署一个恶意合约，并在其回调函数中嵌入对目标取款函数的再次调用。第二步，攻击者向目标合约存入少量资金，建立合法余额记录。第三步，调用取款函数，触发目标向恶意合约转账。第四步，转账回调被触发，恶意合约递归调用取款，在余额清零前反复提取。第五步，目标合约资金被掏空，攻击者一次性提走全部赃款。
这一流程在许多 Sandwich攻击官方文档 之外的链上事件复盘中都有体现，也是为什么审计时会特别关注涉及外部调用的资金路径。涉及跨链场景时，跨链桥官方文档 同样强调对外部调用与状态一致性的严格校验。
防护实践：使用步骤
第一，遵循「检查-生效-交互」（Checks-Effects-Interactions）模式。即先做所有条件检查，再更新合约内部状态（如把余额清零），最后才执行外部转账。仅此一步就能阻断绝大多数经典重入。
第二，引入重入锁。常见做法是使用 OpenZeppelin官方文档 提供的 ReentrancyGuard，通过一个状态变量在函数执行期间加锁，禁止再次进入。
第三，限制外部调用的 gas 与权限，避免向不可信地址发起带回调的转账，并优先使用「拉取式」而非「推送式」的提款设计。
第四，结合自动化工具与人工审计。开发流程中可参考 Hardhat部署官方文档 配置静态分析与测试，在部署前覆盖重入相关的攻击用例。涉及代币逻辑时，还应参照 SPL代币安全审计 等规范对转账钩子进行额外审查。
优势认知与风险提示
理解重入攻击的价值，在于它几乎是所有智能合约安全教育的起点：掌握它，就掌握了「外部调用即风险边界」这一核心安全直觉。
但必须清醒认识到，防护手段并非一劳永逸。重入锁可能被错误地遗漏在某些函数上，只读重入可能绕过传统防护，复杂的跨合约组合也会引入新的重入路径。任何涉及链上资金的逻辑都应假设外部调用是潜在攻击入口。本文仅作技术科普，不构成安全担保，实际部署前务必经过专业审计。
常见问题
问：只要用了 ReentrancyGuard 就绝对安全吗？ 不一定。重入锁只保护被它修饰的函数，跨函数或跨合约的重入路径仍可能存在缝隙，且只读重入往往不在其防护范围内。
问：非以太坊链是否也有重入风险？ 有。任何支持合约间外部调用与回调的执行环境都可能出现类似问题，开发者应查阅对应平台如 Filecoin官方文档 或 Rollup官方文档 的安全建议。
问：普通用户如何降低风险？ 普通用户难以审计合约代码，但可以优先与经过公开审计、运行时间较长、社区口碑良好的协议交互，并对承诺异常高收益的新合约保持警惕。
问：审计能完全消除重入风险吗？ 审计能显著降低风险，但无法保证零漏洞。安全是持续过程，需结合代码规范、自动化测试、形式化验证与持续监控共同保障。