Fallback 函数

什么是 Fallback 函数？

Fallback 函数是 Solidity 中一种特殊函数，用于处理与智能合约中其他已定义函数均不匹配的外部调用。

当 Solidity 无法根据所提供的交易数据识别常规函数时，它就作为合约最后的调用路由选项。

如果调用不包含数据，且合约没有单独的 receive 函数，Fallback 函数也可以运行。

Fallback 函数广泛应用于加密货币应用，包括可升级智能合约、代理系统、模块化钱包、支付合约和自定义调用路由器。

根据Solidity 官方文档，一个合约最多只能包含一个 Fallback 函数。

Fallback 函数必须具有 external 可见性，因为它旨在响应来自合约外部的调用。

如果合约需要通过不匹配的调用接收原生加密货币，该函数可以标记为 payable。

使用该函数的高级形式时，它还可以检查完整交易数据并返回原始响应数据。

Fallback 函数并不是处理所有智能合约操作失败的通用错误处理程序。

只有在 Solidity 和 Ethereum Virtual Machine 定义的特定调用路由条件下，它才会运行。

为什么称为 Fallback 函数？

Fallback 指首选或预期操作不可用时采取的备用操作。

用户调用智能合约的常规函数时，Solidity 会先尝试将所提供的交易数据与合约声明的函数匹配。

如果没有匹配项，合约就会回退到 Fallback 函数。

这种机制允许开发者定义钱包、智能合约或应用发送不受支持的调用时应如何处理。

Fallback 函数可以拒绝调用、接受付款、记录事件、返回数据，或将调用转发到其他合约。

如果合约没有合适的 Fallback 函数，不受支持的调用通常会回滚。

Fallback 函数何时会被调用？

外部调用到达智能合约，且没有常规函数与所提供的函数选择器匹配时，会调用 Fallback 函数。

如果调用包含空 calldata，且合约没有定义 receive 函数，也会调用 Fallback 函数。

无论是否转入原生加密货币，含有非空数据的调用都可能进入 Fallback 函数。

如果调用包含非零加密货币金额，Fallback 函数必须标记为 payable。

不可接收付款的 Fallback 函数会拒绝试图转入金额的未匹配调用。

如果合约定义了 receive 函数，空数据调用会优先进入 receive 函数。

因此，Fallback 函数承担的职责会因合约是否同时包含 receive 函数而不同。

智能合约的函数路由如何运作

智能合约外部调用通常包含编码后的交易数据，称为 calldata。

标准函数调用的前 4 个字节包含函数选择器。

Solidity ABI 规范将选择器定义为函数规范形式的 Keccak-256 哈希值的前 4 个字节。

规范形式由函数名称和参数类型组成。

Solidity 会将传入的选择器与合约 public 和 external 函数的选择器进行比较。

如果存在匹配的选择器，相应函数就会处理该调用。

如果没有匹配的选择器，只要合约提供了 Fallback 函数，Solidity 就会将调用路由到该函数。

少于 4 个字节的 calldata 通常无法识别常规 Solidity 函数，因此可能进入 Fallback 函数。

空 calldata 遵循单独的路由规则，并优先交由 receive 函数处理。

Fallback 函数与 receive 函数

Fallback 函数和 receive 函数是用途不同的 Solidity 独立入口。

receive 函数专门用于处理包含空 calldata 的调用。

Fallback 函数主要用于处理包含数据、但与已声明函数不匹配的调用。

receive 函数始终是 payable，因为它的主要用途是接收原生加密货币。

只有开发者明确允许 Fallback 函数接收金额时，才会将其标记为 payable。

如果合约同时定义了这两个函数，空数据转账会进入 receive 函数。

包含数据的未匹配调用则会进入 Fallback 函数。

如果合约没有 receive 函数，payable 的 Fallback 函数可以处理空数据转账。

Solidity 当前关于接收加密货币的指南建议：如果存在 payable 的 Fallback 函数，应定义 receive 函数。

这种区分有助于将有意的付款与编码错误的函数调用区分开来。

Fallback 函数与常规函数

常规 Solidity 函数有已声明的名称，通常也有自己的函数选择器。

应用可以通过已知的合约接口调用常规函数。

Fallback 函数没有常规可调用名称。

它没有供用户直接调用的专属选择器。

它负责处理与合约常规接口不匹配的调用。

合约可以包含多个常规函数，但只能包含一个 Fallback 函数。

去中心化应用的主要业务逻辑通常应放在常规函数中。

除非有意将 Fallback 函数用作代理路由器，否则其用途应明确且范围有限。

Fallback 函数与错误处理

其他智能合约函数失败时，Fallback 函数不会自动运行。

如果 calldata 与常规函数匹配，而该函数随后回滚，则不会调用 Fallback 函数。

如果匹配的函数因不允许接收付款而拒绝金额，Solidity 不会将该笔付款改送至 Fallback 函数。

如果函数选择器正确但参数格式错误，匹配的调用通常会在解码时回滚。

require 条件失败、算术检查失败、访问控制失败、外部调用失败或触发自定义错误，也不会激活 Fallback 函数。

开发者必须通过常规错误处理、返回值检查、自定义错误或适用的 try-catch 逻辑处理这些失败。

Fallback 函数处理的是未匹配调用，而非匹配调用内部的失败。

什么是 payable Fallback 函数？

Payable Fallback 函数可以接收随未匹配外部调用一同转入的原生加密货币。

调用转入的金额可通过交易的 value 字段读取。

Fallback 函数也可以读取发送方地址。

在 Gas 充足时，payable Fallback 函数可以更新状态、发出事件、转发调用或执行其他允许的操作。

将 Fallback 函数设为 payable 会使合约承担相关资金管理责任。

合约可能需要可靠的余额核算、受控提款、应急流程和重入保护。

如果合约并非用于持有加密货币，通常应拒绝意外转入的款项。

只有在有明确协议用途时，才应启用 payable。

什么是不可接收付款的 Fallback 函数？

不可接收付款的 Fallback 函数可以处理未转入原生加密货币的未匹配调用。

如果未匹配调用包含非零金额，而 Fallback 函数未标记为 payable，该调用就会回滚。

当合约需要自定义路由或记录日志，但不应接收资金时，这种设计很有用。

不可接收付款的 Fallback 函数也可以明确拒绝不受支持的函数选择器。

拒绝未知调用有助于用户和应用发现自己使用了错误的接口。

Fallback 函数可以读取哪些信息？

Fallback 函数可以访问发起当前调用的地址。

如果该函数标记为 payable，它可以访问调用所附带的原生加密货币金额。

它可以检查调用者提供的完整 calldata。

完整 calldata 包含可能的选择器以及其他编码值。

参数化形式的 Fallback 函数可以将这些数据作为字节序列接收。

它还可以直接向调用者返回原始字节。

Solidity 不会自动对 Fallback 函数返回的原始数据进行常规 ABI 编码。

这一特性对代理合约尤其有用，因为代理需要原样返回实现合约的响应。

Fallback 函数是否应解码 calldata？

Fallback 函数可以手动检查并解码 calldata。

可以将前 4 个字节与预期选择器进行比较。

其余字节则可以解码为预期的参数类型。

不过，Solidity 文档建议仅在万不得已时才手动解码 Fallback 数据。

常规命名函数的接口更清晰，自动解码也更安全，且更易于集成。

手动解码必须验证 calldata 长度、偏移量、类型和支持的选择器。

在执行任何敏感状态变更前，应拒绝格式错误的数据。

解码错误可能导致意外行为、交易失败或安全漏洞。

可升级代理合约中的 Fallback 函数

可升级代理合约是 Fallback 函数在加密货币应用中的重要用途之一。

代理将合约地址和存储状态与包含应用业务逻辑的代码分离。

用户向代理地址发送交易。

代理保存包含当前逻辑的实现合约地址。

未匹配代理自身所定义函数的调用会进入其 Fallback 函数。

Fallback 函数会通过 delegatecall 将这些调用转发给实现合约。

Ethereum 关于代理升级的文档说明，这种结构允许业务逻辑发生变化，同时用户仍可与同一个代理地址交互。

更换实现合约后，代理仍保留余额和应用存储数据。

这种方式可以支持修复漏洞和添加新功能，而不必将所有用户迁移到新合约地址。

什么是 Delegatecall？

Delegatecall 是 Ethereum Virtual Machine 的一项操作，可在调用合约的上下文中执行另一合约的代码。

在代理系统中，实现合约提供代码。

代理提供地址、加密货币余额和持久化存储。

委托执行期间，原始发送方和交易金额仍然可用。

因此，实现合约的行为就像其逻辑属于代理合约一样。

EIP-7引入了 delegatecall 这一底层操作，使外部代码可以在保留调用者的发送方和金额上下文的情况下执行。

Delegatecall 功能强大，因为实现合约可以读取和修改代理的存储。

也正因如此，它具有危险性。

恶意或不兼容的实现合约可能破坏余额、权限、所有权数据或其他关键状态。

代理 Fallback 函数如何路由调用

代理首先接收用户的完整 calldata。

其 Fallback 函数会识别当前实现合约的地址。

代理通过 delegatecall 将原始 calldata 转发给该实现合约。

实现合约在代理的存储上下文中执行逻辑。

代理接收实现合约的响应数据。

委托调用成功时，代理会将相同响应返回给原始调用者。

委托调用失败时，代理应将原始错误信息传回调用者。

转发不当可能隐藏错误、修改返回数据，或导致集成应用错误解读结果。

代理存储槽

代理必须在持久化合约存储中的某个位置保存实现合约地址。

该存储位置不得与实现合约所用变量发生冲突。

ERC-1967为代理实现合约、Beacon 和管理员信息定义了标准化存储槽。

这些位置经过专门选择，以避免与 Solidity 编译器分配的常规存储槽冲突。

标准化存储槽也有助于区块链浏览器和开发工具识别代理关系。

采用既定存储槽可以降低意外冲突的可能性，但不能消除所有升级风险。

不同版本的实现合约仍须保持兼容的存储布局。

存储布局风险

升级实现合约时，代理会保留现有数据。

新实现必须以与旧实现相同的方式解读这些存储数据。

改变现有状态变量的顺序，可能导致一个值被误读为另一个值。

更改变量类型可能破坏其含义，或导致无法访问该变量。

更改继承关系也可能改变预期的存储布局。

添加新的状态变量时，必须遵循所选代理架构的存储规则。

升级交易即使成功完成，也可能在不显眼的情况下损坏合约存储。

因此，每次更新实现合约前都必须检查存储兼容性。

函数选择器冲突

函数选择器只有 4 个字节。

理论上，两个不同的函数签名可能生成相同的选择器。

这种情况称为选择器冲突。

当代理和实现合约都定义可调用函数时，选择器冲突尤为重要。

代理可能截获用户原本希望路由到实现合约的选择器。

ERC-1967 指出，选择器冲突可能导致意外响应，甚至可能掩盖代理的恶意行为。

开发者应测试代理函数、实现函数、管理函数及计划升级中所有函数的选择器。

仅凭函数名称，无法证明它的选择器在多个合约中唯一。

升级权限风险

可升级代理通常由某个账户或治理机制控制，只有它们有权更改实现合约地址。

控制该权限的一方可以改变通过 Fallback 函数执行的代码。

升级密钥遭到入侵后，攻击者可能安装转移资产或更改账户余额的实现合约。

恶意管理员也可能用有害逻辑替换正常逻辑。

用户应检查管理员地址、签名者门槛、治理流程、执行延迟、紧急权限和升级历史。

代理 Fallback 函数的源代码已经验证，并不意味着未来的每个实现合约都安全。

可升级性会带来持续的治理和运营信任要求。

Diamond 合约中的 Fallback 函数

Diamond 合约会将不同函数选择器路由到多个称为 Facet 的实现合约。

Fallback 函数检查传入的选择器，并确定负责处理该函数的 Facet。

随后，它通过 delegatecall 将调用转发给选定的 Facet。

ERC-2535为模块化智能合约系统定义了多 Facet 代理架构。

这种设计可以支持逻辑过多、不便由单个实现合约容纳的应用。

也可以添加、替换或移除单独的函数组。

这种灵活性会增加选择器、存储、初始化、权限和升级方面的复杂性。

只审查一个 Facet，无法发现通过 Diamond 地址访问的所有行为。

模块化智能账户中的 Fallback 函数

智能合约账户可以使用 Fallback 处理器添加模块化功能。

处理器可能支持签名、代币回调、账户恢复、会话权限或特定应用接口。

ERC-7579将 Fallback 处理器描述为可扩展智能账户功能的模块。

账户必须控制哪些处理器可以安装、替换和移除。

未经授权的处理器可能导致账户出现意外行为。

钱包用户应了解，更改 Fallback 模块可能会改变账户对外部调用的响应方式。

Gas 与 Fallback 函数

调用者提供足够 Gas 时，Fallback 函数可以执行复杂操作。

它不应假设所有调用者都会提供相同数量的 Gas。

某些旧式加密货币转账方法只会向接收合约转发少量 Gas。

当前 Solidity 文档提醒，send 和 transfer 已被弃用，并计划移除。

少量 Gas 可能不足以支持存储更新、额外转账、创建合约或高成本外部调用。

网络升级也可能改变 Gas 成本。

因此，支付流程不应依赖复杂的 Fallback 逻辑。

开发者不应将少量 Gas 限制视为防范恶意回调的唯一措施。

Fallback 函数的重入风险

只要有足够 Gas，Fallback 函数就可以调用另一个合约。

它可能回调最初发送加密货币或发起交互的合约。

如果发送合约在外部调用完成前尚未完成账目更新，就可能发生重入。

Solidity 关于重入的安全指南说明，外部合约调用可能使控制权在原操作完成前返回。

合约应在进行外部调用前验证条件。

在将控制权交给不受信任的合约前，应更新关键内部状态。

适当的重入保护可以提供另一层防御。

每一次外部调用都应被视为可能执行不受信任代码。

拒绝服务风险

Fallback 函数可能故意或意外回滚。

如果另一个合约要求付款成功后才能完成更大的操作，接收方就可能阻止该操作。

Fallback 函数也可能消耗过多 Gas 或进行高成本外部调用。

如果一笔付款失败就导致整个分发循环回滚，这种问题尤其危险。

Solidity 关于发送加密货币的指南建议，许多支付系统采用基于提款的设计。

提款模式允许每位接收者分别领取资金。

这样一来，某位接收者的 Fallback 行为就不太可能阻碍支付其他用户的款项。

低级调用意外成功的风险

低级调用会报告目标执行成功还是回滚。

执行成功并不能证明预期的命名函数确实存在。

未知选择器可能进入宽松的 Fallback 函数并顺利执行。

只检查成功状态的调用合约可能会错误地认为所请求的操作已经发生。

使用低级调用时，开发者应验证返回数据和预期状态变更。

如果目标函数已知，通常使用类型化接口更安全。

Fallback 函数与原生加密货币

Payable Fallback 函数可以通过未匹配调用接收原生加密货币。

如果合约没有 receive 函数，它也可以处理包含空 calldata 的普通转账。

没有 payable receive 或 Fallback 函数的合约，通常会拒绝普通的直接转账。

不过，合约无法保证自己的余额始终为零。

EVM 存在某些特殊方式，可以在不执行合约 receive 或 Fallback 逻辑的情况下增加其余额。

合约内部记账不应假设实际余额始终等于支付处理函数记录的余额总和。

Fallback 函数与 ERC-20 代币

普通 ERC-20 代币转账不会调用接收合约的 Fallback 函数。

代币合约会在自身存储中更改余额。

接收合约可以在不执行任何代码的情况下获得代币余额。

ERC-20规定，转账由代币合约执行，而非通过强制性的接收方回调完成。

合约不应依赖 Fallback 函数来检测每笔代币存款。

应用通常使用明确的存款函数或单独的余额记账规则。

Fallback 函数与 NFT

某些安全 NFT 转账方法会在目标合约上调用特定的接收方函数。

该接收方函数与通用 Fallback 函数不同。

如果缺少预期的接收方函数，其选择器就无法匹配，调用可能进入 Fallback 函数。

除非合约有意实现所要求的行为，否则宽松的 Fallback 函数不应伪装成支持 NFT 接收。

错误响应可能导致转账回滚，或造成资产找回问题。

Fallback 函数可以发出事件吗？

接收到付款或不受支持的调用时，Fallback 函数可以发出事件。

事件可以记录发送方、转入金额、选择器或其他有用的值。

这些信息有助于开发者监控集成并调查异常活动。

发出事件需要消耗 Gas，如果调用者提供的 Gas 非常有限，操作可能失败。

链上事件是公开的，不应被视为机密记录。

记录完整 calldata 也可能造成不必要的成本，因为交易数据本身已经公开可见。

Fallback 函数可以修改存储吗？

有足够 Gas 时，Fallback 函数可以修改合约存储。

它可以更新计数器、付款记录、权限、路由信息或其他状态。

修改存储会增加 Gas 消耗，并扩大该函数可能造成的安全影响。

如果 Fallback 函数会更改重要状态，就应设置明确的访问控制，并仔细测试相关条件。

当调用者可能只提供有限 Gas 时，接收付款的行为不应依赖存储写入。

Fallback 函数可以继承吗？

Fallback 函数可以参与 Solidity 继承。

它可以声明为 virtual，并由派生合约替换。

它也可以使用修饰符。

如果多个合约包含相关逻辑，继承关系可能使最终调用行为难以理解。

审计人员应审查完整的编译后继承结构，而非只阅读一个源文件。

如何测试 Fallback 函数

开发者应测试包含未知 4 字节选择器的调用。

应测试少于 4 个字节的 calldata。

应测试不附带加密货币的空 calldata。

应测试附带加密货币的空 calldata。

应测试附带和不附带金额的非空未匹配 calldata。

如果存在 receive 函数，应验证调用路由差异。

应测试代理能否正确转发返回数据和回滚数据。

升级测试应确认所有现有存储仍然有效。

安全测试应涵盖重入、选择器冲突、格式错误的 calldata、未经授权的升级和 Gas 不足等情况。

如何审计 Fallback 函数

审计首先应确定哪些类型的调用会进入 Fallback 函数。

审计人员应确认该函数是否为 payable。

还应检查合约是否单独定义了 receive 函数。

应检查每一项存储更新、外部调用、修饰符、汇编操作和权限验证。

代理审计必须验证实现合约地址的选择方式。

未经授权的用户不得更改 delegatecall 的目标地址。

返回数据和回滚数据必须准确转发。

实现合约升级必须保持存储兼容性。

审查还应涵盖管理员、治理流程、升级延迟和紧急控制措施。

Fallback 函数最佳实践

尽可能使用常规命名函数处理普通应用行为。

如果合约确实需要接收普通原生加密货币转账，应单独定义 receive 函数。

无需自定义路由时，应拒绝不受支持的选择器。

保持与付款相关的 Fallback 行为简单。

将所有 calldata 和调用者都视为不受信任。

手动解码前验证选择器和数据长度。

使用经过审查的代理标准，不要自行创建未经测试的转发逻辑。

保护实现合约、管理员和 Beacon 的存储位置。

升级时保持存储布局兼容。

为每个升级函数设置明确的访问控制。

转发调用时，准确返回成功数据和失败数据。

采用安全的状态更新顺序并实施适当的重入保护。

测试普通钱包界面可能不会生成的特殊调用。

使用当前稳定版本的 Solidity 编译器，并查看官方已知编译器漏洞列表。

Fallback 函数的常见错误

一种常见错误是认为匹配的函数回滚后，Fallback 函数会运行。

另一种错误是在没有安全提款机制的情况下，将函数设为 payable。

有些合约通过 Fallback 函数接受普通付款，却没有定义更明确的 receive 函数。

手动解码 calldata 时，可能没有先检查数据长度。

低级调用的调用方可能误以为 Fallback 函数执行成功，就代表请求的函数也已成功执行。

代理可能将实现合约地址存储在与应用状态冲突的位置。

升级时可能重排变量，导致余额或权限遭到破坏。

不受限制的 delegatecall 目标可能允许任意代码在代理上下文中执行。

复杂的 Fallback 函数可能因可用 Gas 低于预期而失败。

开发者可能错误地认为 ERC-20 转账会触发 Fallback 函数。

关于 Fallback 函数的常见误解

Fallback 函数不是通用的智能合约错误处理程序。

并非每笔失败的交易都会调用它。

它不会自动成为 payable。

它并不总是接收普通加密货币付款的正确函数。

一个合约最多只能包含一个 Fallback 函数。

Fallback 函数没有常规函数选择器。

即使没有转入加密货币，它也可以处理未匹配的 calldata。

Fallback 函数成功执行，并不能证明调用者使用了正确的合约接口。

代理 Fallback 路由可能使用户面临并未存储在代理地址上的代码风险。

仅验证代理源代码，并不能证明其当前实现安全。

常见问题

Solidity 中的 Fallback 函数是什么？

Fallback 函数是一种特殊的 external 函数，用于处理与智能合约其他函数不匹配的调用。

Fallback 函数何时运行？

没有已声明函数与所提供的选择器匹配时，或 calldata 为空且合约没有 receive 函数时，它会运行。

一个合约可以有多个 Fallback 函数吗？

不可以。一个 Solidity 合约最多只能有一个 Fallback 函数。

Fallback 函数有名称吗？

没有。它通过 fallback 关键字声明，而非使用普通函数名称。

Fallback 函数必须是 external 吗？

是。Fallback 函数必须使用 external 可见性。

Fallback 函数会自动成为 payable 吗？

不会。只有明确标记为 payable 时，它才能接收原生加密货币。

向不可接收付款的 Fallback 函数转入金额会怎样？

如果未匹配调用试图转入非零金额，该调用就会回滚。

Fallback 函数与 receive 函数有什么区别？

receive 函数处理空 calldata，Fallback 函数则主要处理与已声明函数不匹配的调用。

哪个函数处理普通的加密货币转账？

如果存在 receive 函数，由它处理；只有合约没有 receive 函数时，payable Fallback 函数才会处理。

其他函数失败后，Fallback 函数会运行吗？

不会。匹配函数内部的失败不会将执行重定向到 Fallback 函数。

Fallback 函数可以检查交易数据吗？

可以。它可以访问调用者提供的完整 calldata。

Fallback 函数可以返回数据吗？

可以。其高级形式可以直接向调用者返回原始字节。

代理合约为什么使用 Fallback 函数？

代理合约使用它通过 delegatecall 将用户调用转发给实现合约。

Delegatecall 会保留什么？

它会保留原始发送方和金额，同时针对代理的存储和余额执行实现合约代码。

Delegatecall 会修改实现合约的存储吗？

不会。委托执行的实现代码通常读取和写入的是调用方代理的存储。

什么是实现合约？

实现合约是包含通过可升级代理执行的业务逻辑的合约。

什么是选择器冲突？

不同函数签名生成相同 4 字节选择器时，就会发生选择器冲突。

为什么存储布局很重要？

存储布局不兼容可能导致升级后的实现合约误读或覆盖代理现有数据。

Fallback 函数会导致重入吗？

会。在有足够 Gas 时，它可能回调另一个合约。

Fallback 函数可以拒绝付款吗？

可以。不可接收付款的 Fallback 函数或明确回滚的 Fallback 函数，可以拒绝普通消息调用形式的付款。

合约能阻止余额以任何方式增加吗？

不能。某些 EVM 机制可以在不执行 receive 或 Fallback 逻辑的情况下增加合约余额。

ERC-20 转账会触发 Fallback 函数吗？

通常不会，因为代币合约会更新余额，而不会调用接收方。

Fallback 函数可以发出事件吗？

可以，但调用必须提供足够 Gas 才能执行事件操作。

Fallback 函数可以更新存储吗？

可以，但存储更新会增加成本，且可用 Gas 不足时可能失败。

Fallback 函数可以使用修饰符吗？

可以，Fallback 函数可以使用 Solidity 修饰符。

Fallback 函数可以继承吗？

可以。它可以声明为 virtual，并由派生合约重写。

低级调用成功能证明请求的函数存在吗？

不能。未知选择器可能已被 Fallback 函数接受。

每个智能合约都应该有 Fallback 函数吗？

不应该。只有在需要自定义处理未匹配调用时，才应定义 Fallback 函数。

可升级合约中的 Fallback 函数安全吗？

如果转发逻辑、存储布局、实现合约和升级权限设计合理并经过审计，它可以是安全的。

Fallback 函数最大的风险是什么？

风险取决于其用途，但代理委托、未受限制的外部调用、不安全的升级和意外付款行为都可能构成严重风险。

结论

Fallback 函数是 Solidity 中的特殊入口，用于处理与其他已声明智能合约函数不匹配的外部调用。

如果合约没有定义 receive 函数，它也可以处理空 calldata。

Payable Fallback 函数可以接收原生加密货币，而不可接收付款的 Fallback 函数会拒绝携带金额的未匹配调用。

有意接收普通加密货币转账时，通常应使用更明确的 receive 函数。

Fallback 函数对于可升级代理至关重要，因为它可以通过 delegatecall 将调用转发给实现合约。

这一过程会保留原始发送方和金额，同时针对代理的存储执行实现合约代码。

基于代理的 Fallback 路由会带来存储布局、选择器冲突、升级权限和 delegatecall 风险。

Fallback 函数还可能引发重入、拒绝服务、Gas、数据解码和低级调用意外成功等问题。

开发者应限制 Fallback 函数的行为范围，在适当情况下拒绝不受支持的调用，并使用常规命名函数处理普通应用逻辑。

理解 Fallback 函数对于评估加密货币智能合约至关重要，因为这个没有名称的入口可能控制付款、代理路由、模块化账户行为，以及整个去中心化应用的执行。