Solidity 执行概览：Payable、Fallback、调用类型与回滚详解

当我们编写 Solidity 代码时，很容易从函数和修饰符的角度思考，但在底层，与合约的每一次交互都变成了由以太坊虚拟机 (EVM) 执行的原始操作码、calldata 和消息调用。

在这篇文章中，我们将跳出字节码的范畴，探讨 Solidity 的高级特性如何映射到实际的 EVM 行为：合约如何接收 Ether，不同调用类型如何改变上下文，以及函数 revert 时真正发生了什么。

我们将介绍每个开发者都应该理解的机制，以便自信地推断执行流程和故障处理：

1.payable、receive 和 fallback 函数用于接受 Ether

2. 低级调用家族：CALL、DELEGATECALL、STATICCALL、CALLCODE

3. 内部和外部函数调用的区别

4. revert 如何传播以及它们为何被设计为安全

读完本文，你将对 Solidity 代码从交易进入 EVM 到返回、revert 或将控制权转移到另一个合约的那一刻，实际是如何执行的，有一个清晰的认识。

Payable、Fallback 和 Receive

Payable

在 Solidity 中，payable 关键字将函数或地址标记为能够接收 Ether。没有它，函数或地址不能接受 ETH，任何试图向其发送 ETH 的交易都将自动revert。

payable 是一个安全特性。它防止合约意外接受 ETH 或与意外的价值转移进行交互，这在可升级合约或代理中特别有用。

示例：

// For functions
function deposit() external payable {
    // msg.value contains the ETH sent with the call (msg.value 包含随调用发送的 ETH)
}

// For addresses
address payable recipient = payable(someAddress);
recipient.transfer(1 ether);

Receive

合约可以定义最多一个receive() 函数，写法如下：

receive() external payable { ... }

这里发生的情况：

• 必须是 external 和 payable。
• 不能接受参数或返回任何值。
• 当使用空 calldata 发送 Ether 时触发 — 例如 .send() 或 .transfer()。
• 如果不存在 receive() 但存在 payable fallback()，则改用该 fallback。
• 如果两者都不存在，交易将revert 并且 Ether 会返回给发送者。

注意： 当以这种方式发送 Ether 时，可用 gas 限制为 2300 ，这足以触发事件，但 不足以 写入存储、调用其他合约或发送 ETH。

示例：

contract MyContract{
    event Received(address sender, uint amount);

    receive() external payable {
            emit Received(msg.sender, msg.value);
    }
}

Fallback

合约也可以定义一个fallback() 函数，例如：

fallback() external [payable] { ... }
// or with calldata access and return: (或带有 calldata 访问和返回：)
fallback(bytes calldata input) external [payable] returns (bytes memory)

在以下情况下被调用：

• 没有函数匹配调用
• 如果 calldata 为空且不存在 receive() 函数

将其标记为 payable 以接收 ETH。可以访问 msg.data (calldata) 并返回原始字节。

示例：

contract Example {
    fallback() external payable {
        // triggered on unknown function calls or empty calldata if no `receive()`
        // (在未知函数调用或 calldata 为空且没有 `receive()` 时触发)
    }
}

总结

如果 receive() 和 payable fallback() 都存在：

• 空 calldata → 使用 receive()
• 非空 calldata (即使是未知函数) → 使用 fallback()

没有两者之一 的合约无法通过 .send() 或 .transfer() 接收普通 ETH。

Ether 仍然可以通过以下方式到达：

• selfdestruct(address)
• 区块奖励 (coinbase)

但合约不会响应，没有代码运行。

更多信息可在此处找到 here。

CALL、DELEGATECALL、STATICCALL、CALLCODE

Call

在新的上下文中执行来自另一个合约 (address) 的代码。

上下文行为：

• msg.sender → 变为调用合约。
• msg.value → 通过调用传递的值。

存储：使用被调用合约的存储。

为何有用：发送 ETH，调用外部函数，完全灵活。

典型用法：低级函数调用 (.call{...}(calldata))，ETH 转移。

常见风险：重入 — 因为完全控制权被移交给外部代码。

Delegate Call

在你自己的执行上下文中运行来自另一个合约的代码。

上下文行为：

• msg.sender 和 msg.value → 被保留 (与原始交易相同)。

存储：使用调用者的存储。

为何有用：启用可升级合约和代理模式。

典型用法：透明代理合约将逻辑委托给共享实现。

常见风险：如果存储布局不匹配，状态可能会损坏。

Static Call

调用另一个合约，只读。

上下文行为：

• msg.sender 和 msg.value → 被保留。

不允许写入：任何存储修改都会导致 revert。

为何有用：安全的外部视图调用 — 没有状态更改的风险。

典型用法：视图/纯函数、只读聚合器、链上验证器。

常见限制：不能调用写入状态的函数 — 即使是间接写入。

Call Code

执行来自另一个合约的代码，但写入你自己的存储。

上下文行为：

• msg.sender 和 msg.value → 设置为直接调用者 (不被保留)。

存储：调用者的存储被修改。

为何有风险：msg.sender 和存储上下文之间的不匹配导致了 bug。

现代状态：已弃用，转而使用 DELEGATECALL — 避免使用。

内部和外部函数调用

在处理智能合约时，理解内部和外部函数调用之间的区别至关重要，因为它们会影响执行上下文、gas 效率和安全性。

内部调用

当合约中的一个函数调用同一合约内的另一个函数或继承的函数时，就会发生内部调用。这些调用由 EVM 通过 JUMP 或 JUMPDEST 操作码直接处理，而不是通过消息调用，这使得它们在 gas 方面更高效。

• 不涉及 calldata
• 通过直接控制流 (基于跳转) 执行
• 保留 msg.sender 和 msg.value

示例：

contract MyContract {
    function publicCaller() public {
        internalFunction(); // Internal call (内部调用)
    }

    function internalFunction() internal {
            // logic here (逻辑代码)
    }
}

外部调用

外部调用涉及从合约外部调用函数，即使是调用同一合约的地址。这是通过消息调用完成的，并通过 CALL、DELEGATECALL 或 STATICCALL 等操作码进行处理。

• Calldata 被 ABI 编码并传递到 EVM 中
• 被视为新的交易上下文
• 由于上下文切换，gas 成本更高
• 可以与其他合约交互
• 上下文根据前一节的解释而改变

interface Token {
    function transfer(address to, uint256 amount) external returns (bool);
}

contract Caller {
    function paySomeone(address token, address recipient, uint256 amount) external {
        // External call: ABI-encoded calldata is sent to the token contract
        // (外部调用：ABI 编码的 calldata 被发送到代币合约)
        Token(token).transfer(recipient, amount);
    }
}

以下是底层发生的事情：

• Token(token) 将原始地址转换为类型化接口。

Solidity 编译器为 transfer(address,uint256) 生成 ABI 编码的 calldata：

• 前 4 字节：函数选择器 (keccak256("transfer(address,uint256)"))
• 随后是：32 字节编码的 recipient，以及 32 字节编码的 amount。

CALL 操作码用于将此数据传递给 token 合约。

该调用在隔离的子上下文中执行：

• msg.sender 变为 Caller (而不是原始交易发送者)。
• storage 和 code 来自目标合约 (代币)。

revert 如何工作 (并向上冒泡)

在 EVM 中，reverts 是智能合约在出现问题时安全地撤销状态更改的方式。

当 REVERT 操作码执行时：

• 调用期间对存储的所有更改被回滚 (即 revert)。
• 剩余的 gas 不被消耗。
• revert 原因 (可选) 作为 ABI 编码的数据返回。

reverts 可以手动调用：

require(x > 0, "x must be positive");
//or (或者)
revert("custom error message");

当一个合约调用另一个合约 (通过 CALL、DELEGATECALL 等) 并且被调用者revert时，revert 将“向上冒泡”到调用者：

• 由调用者来处理或传播该错误。
• 在 Solidity 中，如果未通过 try/catch 捕获，它将自动向上冒泡并使调用者也 revert。

示例：

function outer() public {
    inner(); // If `inner()` reverts, so does `outer()` (如果 `inner()` revert，`outer()` 也会 revert)
}

function inner() public {
    require(false, "fail");
}

或者它可以被捕获：

try otherContract.doSomething() {
    // success (成功)
} catch Error(string memory reason) {
    // reason is the revert message (reason 是 revert 消息)
} catch {
    // catch all (e.g., invalid opcode) (捕获所有错误 (例如，无效操作码))
}

为何重要

简而言之，Solidity 的执行模型是围绕受控的消息调用和明确定义的故障传播构建的。

一旦你理解了这些机制，调试和推理智能合约就会容易得多。

总结

每当一个合约通过 call、delegatecall 或 staticcall 调用另一个合约时，EVM 都会启动一个新的调用上下文，就像一个带有自己的栈、内存和 msg.sender/value (取决于调用类型) 的全新迷你 EVM。

如果该调用失败，它会revert 自己的状态更改并将错误传回 (向上冒泡) 给其调用者，除非通过 try/catch 处理。这种机制允许 Solidity 构建复杂、可组合的系统，同时仍保持强大的故障安全性。

• 原文链接： medium.com/@andrey_obruc...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～