Fallback 函式

什麼是 Fallback 函式？

Fallback 函式是 Solidity 中的一種特殊函式，用來處理外部呼叫中未能對應智能合約其他已定義函式的呼叫。

當 Solidity 無法根據提供的交易資料識別一般函式時，它會作為合約最後一道呼叫路由選項。

若呼叫不含資料，且合約沒有另外定義 receive 函式，也可能執行 Fallback 函式。

此函式廣泛用於加密貨幣應用程式，包括可升級智能合約、代理系統、模組化錢包、支付合約及自訂呼叫路由器。

根據Solidity 官方文件，一個合約最多只能包含一個 Fallback 函式。

Fallback 函式必須具備 external 可見性，因為它是用來回應來自合約外部的呼叫。

若合約需要透過未匹配的呼叫接收原生加密貨幣，Fallback 函式可以標記為 payable。

使用進階形式時，也可以檢查完整交易資料並回傳原始回應資料。

Fallback 函式不是處理所有智能合約操作失敗的一般錯誤處理器。

它只會在 Solidity 及 Ethereum Virtual Machine 定義的特定呼叫路由條件下執行。

為什麼稱為 Fallback 函式？

Fallback 一詞表示當偏好或預期的操作無法使用時，採取的替代行動。

使用者呼叫一般智能合約函式時，Solidity 會先嘗試將提供的交易資料與合約宣告的函式相匹配。

如果找不到匹配項，合約就會回退至 Fallback 函式。

這項功能讓開發者能定義錢包、智能合約或應用程式送出不受支援的呼叫時，合約應如何處理。

Fallback 函式可以拒絕呼叫、接受付款、記錄事件、回傳資料，或將呼叫轉送至另一個合約。

若合約沒有合適的 Fallback 函式，不受支援的呼叫通常會回退交易。

Fallback 函式何時會被呼叫？

外部呼叫抵達智能合約，且沒有一般函式符合所提供的函式選擇器時，就會呼叫 Fallback 函式。

若呼叫包含空 calldata，且合約未定義 receive 函式，也會呼叫 Fallback 函式。

無論是否轉移原生加密貨幣，只要呼叫含有非空資料，都可能進入 Fallback 函式。

呼叫包含非零加密貨幣價值時，Fallback 函式必須標記為 payable。

非 payable 的 Fallback 函式會拒絕嘗試轉移價值的未匹配呼叫。

若合約定義 receive 函式，空資料呼叫會優先進入 receive 函式。

因此，合約是否同時包含 receive 函式，會影響 Fallback 函式的職責。

Solidity 目前關於接收加密貨幣的指引建議，若存在 payable 的 Fallback 函式，應另行定義 receive 函式。

這種區分有助於分辨刻意付款與編碼錯誤的函式呼叫。

智能合約函式路由如何運作？

外部智能合約呼叫通常包含編碼後的交易資料，稱為 calldata。

標準函式呼叫的前 4 個位元組包含函式選擇器。

Solidity ABI 規格將選擇器定義為函式標準簽章 Keccak-256 雜湊的前 4 個位元組。

標準簽章由函式名稱及其參數類型組成。

Solidity 會將輸入的選擇器與合約公開及外部函式的選擇器比較。

若有匹配的選擇器，相應函式就會處理呼叫。

若沒有匹配的選擇器，且合約提供 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。

什麼是 Nonpayable Fallback 函式？

Nonpayable Fallback 函式可以處理不轉移原生加密貨幣的未匹配呼叫。

未匹配呼叫若帶有非零價值，且 Fallback 函式不是 payable，交易就會回退。

若合約需要自訂路由或記錄日誌，但不應接收資金，這種設計便很有用。

Nonpayable 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 功能強大，因為實作合約可以讀取及修改代理合約的儲存資料。

也正因如此，Delegatecall 具有危險性。

惡意或不相容的實作合約可能破壞餘額、權限、所有權資料或其他重要狀態。

代理 Fallback 函式如何路由呼叫

代理合約會先接收使用者的完整 calldata。

其 Fallback 函式會識別目前的實作地址。

代理合約透過 delegatecall，將原始 calldata 轉送至該實作合約。

實作合約會使用代理合約的儲存資料執行邏輯。

代理合約會接收實作合約傳回的資料。

委派呼叫成功時，代理合約會將相同回應傳回原始呼叫者。

委派呼叫失敗時，代理合約應將原始錯誤資訊傳回呼叫者。

錯誤轉送可能隱藏錯誤、修改回傳資料，或讓整合系統誤解結果。

代理合約的儲存槽位

代理合約必須在合約永久儲存空間中的某個位置記錄實作合約地址。

該儲存位置不得與實作合約使用的變數衝突。

ERC-1967 為代理實作、信標及管理員資訊定義標準化儲存槽位。

這些位置經過選定，可避免與 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 及呼叫者視為不受信任。

手動解碼前，應驗證選擇器及資料長度。

應使用經審查的代理標準，而非建立未經測試的轉送邏輯。

保護實作合約、管理員及信標的儲存位置。

升級期間維持儲存配置。

對每項升級函式實施明確的存取控制。

轉送呼叫時，準確回傳成功資料及失敗資料。

採用安全的狀態更新順序及適當的重入防護。

測試一般錢包介面可能不會產生的特殊呼叫。

使用目前穩定版 Solidity 編譯器，並檢視官方已知編譯器錯誤清單。

Fallback 函式的常見錯誤

常見錯誤之一，是以為匹配的函式回退後會執行 Fallback 函式。

另一個錯誤是將函式設為 payable，卻沒有安全的提領系統。

有些合約透過 Fallback 函式接受一般付款，卻未定義用途更明確的 receive 函式。

手動解碼 calldata 時，可能未先檢查資料長度。

低階呼叫者可能將 Fallback 函式執行成功，誤認為要求的函式也成功執行。

代理合約可能將實作合約地址存放在與應用程式狀態衝突的位置。

升級時重新排列變數，可能破壞餘額或權限。

不受限制的 delegatecall 目標可能讓任意程式碼在代理合約的執行環境中執行。

複雜的 Fallback 函式在可用 Gas 低於預期時可能失敗。

開發者也可能錯誤地認為 ERC-20 轉帳會觸發 Fallback 函式。

對 Fallback 函式的常見誤解

Fallback 函式不是通用的智能合約錯誤處理器。

並非每筆失敗交易都會呼叫它。

它不會自動成為 payable。

接收一般加密貨幣付款時，Fallback 函式不一定是正確選擇。

一個合約最多只能有一個 Fallback 函式。

Fallback 函式沒有一般函式選擇器。

即使沒有轉移加密貨幣，它仍可處理未匹配的 calldata。

Fallback 函式執行成功，不代表呼叫者使用了正確的合約介面。

代理合約的 Fallback 函式可能讓使用者執行並未儲存在代理地址中的程式碼。

只驗證代理合約的原始碼，不能證明目前的實作合約安全。

常見問題

Solidity 中的 Fallback 函式是什麼？

Fallback 函式是特殊的外部函式，用來處理無法匹配智能合約其他函式的呼叫。

Fallback 函式何時執行？

沒有已宣告函式符合提供的選擇器，或 calldata 為空且不存在 receive 函式時，就會執行。

合約可以有多個 Fallback 函式嗎？

不可以。Solidity 合約最多只能有一個 Fallback 函式。

Fallback 函式有名稱嗎？

沒有。它使用 fallback 關鍵字宣告，而非一般函式名稱。

Fallback 函式必須是 external 嗎？

是。Fallback 函式必須使用 external 可見性。

Fallback 函式會自動成為 payable 嗎？

不會。只有明確標記為 payable 時，它才會接收原生加密貨幣。

向 Nonpayable Fallback 函式傳送價值時會怎樣？

嘗試轉移非零金額時，未匹配的呼叫會回退。

Fallback 與 Receive 有什麼不同？

Receive 處理空 calldata；Fallback 主要處理無法匹配已宣告函式的呼叫。

哪個函式會處理一般加密貨幣轉帳？

存在 receive 函式時由其處理；只有在沒有 receive 函式時，payable Fallback 函式才會處理。

其他函式失敗後會執行 Fallback 嗎？

不會。匹配函式內部發生錯誤，不會將執行改送至 Fallback 函式。

Fallback 可以檢查交易資料嗎？

可以。它能存取呼叫者提供的完整 calldata。

Fallback 可以回傳資料嗎？

可以。其進階形式可直接向呼叫者回傳原始位元組。

代理合約為什麼使用 Fallback？

代理合約透過 Fallback，使用 delegatecall 將使用者呼叫轉送至實作合約。

Delegatecall 會保留什麼？

它會保留原始發送者及價值，同時使用代理合約的儲存資料與餘額執行實作程式碼。

Delegatecall 會修改實作合約的儲存資料嗎？

不會。委派執行的實作程式碼通常讀寫的是呼叫它的代理合約儲存資料。

什麼是實作合約？

實作合約包含透過可升級代理執行的業務邏輯。

什麼是選擇器衝突？

不同函式簽章產生相同的 4 位元組選擇器時，就會發生選擇器衝突。

儲存配置為什麼重要？

儲存配置不相容，可能使升級後的實作合約誤讀或覆寫代理合約的既有資料。

Fallback 會造成重入嗎？

會。若有足夠 Gas，它可以再次呼叫另一個合約。

Fallback 可以拒絕付款嗎？

可以。Nonpayable 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 函式可以接收原生加密貨幣；Nonpayable Fallback 函式則會拒絕附帶價值的未匹配呼叫。

若要刻意接收一般加密貨幣轉帳，通常使用 receive 函式會更清楚。

Fallback 函式對可升級代理合約至關重要，因為它可以透過 delegatecall 將呼叫轉送至實作合約。

這個流程會保留原始發送者及價值，同時使用代理合約的儲存資料執行實作程式碼。

以代理為基礎的 Fallback 路由會帶來儲存配置、選擇器衝突、升級權限及 delegatecall 風險。

Fallback 函式也可能造成重入、阻斷服務、Gas、解碼及低階呼叫意外成功等問題。

開發者應限制 Fallback 函式的用途、適時拒絕不受支援的呼叫，並使用一般命名函式處理一般應用程式邏輯。

了解 Fallback 函式是評估加密貨幣智能合約的重要環節，因為這個未命名的進入點可能控制付款、代理路由、模組化帳戶行為，以及整個去中心化應用程式的執行。