Solidity重入防护：先更新状态变量、触发事件是否合理？

1. 先更新状态变量再发起外部调用是否合理？ #

完全合理，这是Solidity中防范重入攻击的标准方案（即Checks-Effects-Interactions模式）。

• 重入攻击的核心逻辑是攻击者通过外部调用回调合约，利用合约未更新状态的漏洞重复获取资产。
• 先完成状态更新（比如扣除用户余额、标记操作已处理），再发起外部调用，即便攻击者回调合约，合约的状态已经是最新的，无法再执行重复的资产转移逻辑，从根源上阻断重入可能。
  示例代码：

function withdraw(uint amount) external {
    // Checks：验证余额充足
    require(balances[msg.sender] >= amount, "Insufficient balance");
    // Effects：优先更新状态
    balances[msg.sender] -= amount;
    // Interactions：最后发起外部调用
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

2. 事件应在外部调用前还是后触发？ #

需根据事件的实际用途判断：

• 若事件用于记录状态变更的确认（比如用户余额已扣除、提现请求已处理）：建议在状态更新后、外部调用前触发。此时状态已完成变更，事件能准确反映合约内部状态，即便后续外部调用失败，整个交易会回滚，事件也不会被上链，不会留下不一致的链上记录。
• 若事件用于记录操作的发起（比如提现请求已提交）：可在外部调用前触发，但同样，若调用失败，交易回滚后事件也不会被记录在链上。
• 不建议在外部调用后触发事件：如果外部调用成功但后续逻辑（若存在）失败，事件会随交易回滚；若仅在调用后触发，调用失败时用户无法从链上事件看到操作发起痕迹（但交易失败本身会在链上留有记录）。

3. 先触发事件但后续外部调用失败，该如何处理？ #

无需额外处理，因为Solidity交易具备原子性：

• 一旦外部调用失败（比如转账失败、合约抛出异常），整个交易的所有状态变更、事件触发都会被回滚，不会在链上留下任何痕迹。
• 用户可通过查询交易状态（失败）得知操作未完成，合约无需额外逻辑处理该情况，所有操作会自动回到交易执行前的初始状态。

内容的提问来源于stack exchange，提问作者Bhanu Partap