Gas 最佳化技術

什麼是 Gas 最佳化技術？

Gas 最佳化技術是用來減少加密貨幣交易或智能合約所需運算資源與區塊鏈儲存空間的方法。

在 Ethereum 與其他 EVM 相容網路上，Ethereum Virtual Machine 的每項操作都有 Gas 成本。

讀取合約儲存資料、變更區塊鏈狀態、複製資料、呼叫其他合約、產生事件，以及部署位元組碼，都會消耗 Gas。

提交交易的使用者通常須依計收的 Gas 與交易有效 Gas 價格支付費用。

基本公式為：交易手續費 = 計收的 Gas × 有效 Gas 價格。

Gas 最佳化可降低公式中的計收 Gas 部分。

它不會直接控制每個 Gas 單位的市場價格；價格會隨區塊空間需求變動。

經過良好最佳化的合約可降低使用者成本、讓每個區塊容納更多活動、提高交易可靠性，並讓去中心化應用程式在網路需求高時更實用。

但 Gas 最佳化絕不能削弱存取控制、運算安全性、防重入保護、帳務準確性或其他安全屬性。

最佳的最佳化方式通常是採用更簡單的設計、減少工作量，而不是只為省下少量 Gas 寫出複雜程式碼。

Gas 最佳化為什麼對加密貨幣很重要

每一項不必要的鏈上操作，都會增加提交交易的個人或應用程式成本。

單筆交易的成本差異可能不大，但智能合約處理數千或數百萬次互動時，累積費用就可能相當可觀。

降低 Gas 用量可讓代幣轉帳、去中心化金融操作、NFT 活動、治理投票與區塊鏈遊戲更實惠。

高效率合約需要較少的儲存讀取、寫入與運算步驟，也更容易由驗證者與節點處理。

對於會執行重複迴圈、更新多個餘額、建立新合約，或在單筆交易中呼叫多個外部系統的應用程式，Gas 最佳化尤其重要。

這也攸關自動化加密貨幣策略，因為較高的執行成本可能抵銷交易或強制平倉的預期獲利。

Gas 最佳化無法保證交易以國家貨幣計價時的費用低廉，因為 Gas 價格與原生加密貨幣市場價格仍可能上漲。

它能減少使用者必須付費的網路工作量。

了解 Gas 的消耗來源

開發者在修改智能合約程式碼前，應先了解 Gas 消耗的主要來源。

持久儲存通常是最昂貴的資源之一，因為產生的資料必須持續保留在區塊鏈狀態中。

記憶體是單次執行期間使用的暫存資料，通常比持久儲存便宜；但配置的記憶體區域擴大時，成本也會增加。

Call data 包含交易或外部函式輸入；除非複製，否則不會成為可修改的合約記憶體。

合約部署會因執行初始化程式碼，以及儲存產生的執行時位元組碼而消耗 Gas。

外部合約呼叫會產生帳戶存取、參數編碼、回傳資料處理，以及被呼叫合約執行工作的額外成本。

密碼學運算、事件日誌、合約建立與大型迴圈，也可能大幅增加 Gas 用量。

官方 Ethereum Gas 文件說明，Gas 用來衡量交易與 EVM 操作所需的運算工作量。

最佳化前先測量 Gas

Gas 最佳化應從測量開始，而非依賴假設。

開發者應在修改程式碼前，記錄重要函式的部署成本與執行成本。

測試應涵蓋實際交易規模、一般使用者行為、支援的最大輸入、失敗路徑及少見的區塊鏈狀態。

含有一個陣列元素的函式可能成本不高，但含有 1,000 個元素時可能變得不安全或難以負擔。

Gas 快照可比較不同程式碼版本的函式成本，並偵測意外增加。

執行追蹤可顯示哪些操作碼、儲存欄位、內部呼叫與外部呼叫消耗最多 Gas。

Solidity 編譯器可產生 Gas 估算值，詳見其編譯器文件；但若執行取決於動態迴圈或外部合約行為，有些估算可能無法取得或不可靠。

在本機區塊鏈或持續維護的公開測試網上測試，可取得較貼近實際的測量結果。

開發者應最佳化使用者實際會執行的高成本路徑，而不是將時間花在極少呼叫的程式碼上。

使用目前版本的 Solidity 編譯器

較新的 Solidity 編譯器版本通常包含程式碼產生改良、最佳化修正、新 EVM 指令支援與安全性修補。

Solidity 官方網站於 2026 年 7 月列出的最新正式發布編譯器版本為 0.8.36。

選擇正式環境編譯器前，開發者應查看Solidity 官方網站與已知編譯器錯誤清單。

所選版本應固定在建置設定中，讓每位開發者、測試系統與部署流程都產生一致的位元組碼。

若未控制實際建置環境而使用寬鬆的 pragma，不同編譯器版本可能產生不同程式碼。

即使使用較新的編譯器，也應仔細測試，因為最佳化與語言變更可能影響位元組碼、部署成本及合約行為。

啟用並設定 Solidity 最佳化器

Solidity 最佳化器會簡化運算式、移除不必要操作、合併重複計算，並可能降低部署位元組碼與執行時 Gas 消耗。

Solidity 最佳化器文件說明，最佳化可縮減程式碼大小與執行成本。

最佳化器的 runs 設定代表開發者預期部署的程式碼會執行多少次。

較低的 runs 值通常更著重縮小部署位元組碼。

較高的 runs 值通常允許編譯器產生部署時較大的程式碼，以降低重複執行成本。

沒有任何 runs 值適用於所有加密貨幣合約。

部署多次但很少呼叫的合約，適用設定可能與預期處理數百萬筆交易的合約不同。

開發者應使用實際測試比較多種設定，並評估完整生命週期成本，而非只看部署或執行成本。

via-IR 編譯流程可能產生與舊版流程不同的最佳化結果；切換流程應視為重要的建置變更，並進行完整測試。

減少持久儲存寫入

持久儲存寫入通常是最有機會節省 Gas 的部分。

若資訊能從現有狀態安全推算，或在需要時由使用者提供，合約就應避免儲存該資訊。

若合約能先確認數值無須變更，就應避免重複寫入相同數值。

使用更簡單、寫入次數更少的帳務模型，可能比更新 5 個不同狀態變數更省成本。

開發者也應考慮其他智能合約是否需要取得該資訊，或只有鏈下應用程式需要。

會影響合約未來執行的資料通常應儲存在 storage 中。

若錢包、介面或分析工具才需要資訊，有時可改為記錄在事件中。

依照 Ethereum 現行規則，刪除儲存資料可取得有限的 Gas 退款，但退款有上限，不應視為讓儲存免費的方式。

合約應基於合理的設計理由移除過時狀態，而不是為了期待日後退款而建立不必要資料。

快取重複的儲存讀取

若底層狀態在多次讀取期間不需變更，先讀取儲存欄位一次並重複使用本地數值，比一再讀取更省 Gas。

Ethereum 依據 EIP-2929 區分冷狀態存取與暖狀態存取。

交易中首次存取先前未觸及的儲存欄位屬於冷存取，費用較高。

同一筆交易中再次存取相同欄位時，則屬於暖存取，成本較低。

即使是暖儲存讀取，成本仍可能高於使用函式中已可取得的堆疊或記憶體值。

函式通常可將常用狀態變數複製到本地變數，進行計算後再一次寫回最終結果。

如果外部呼叫可能改變相關狀態，或快取值會因此過時，就不應使用此方法。

開發者應遵守「檢查－效果－互動」原則，並在外部呼叫前後快取狀態時仔細分析重入風險。

謹慎打包狀態變數

Ethereum 儲存空間以 32 位元組的欄位為單位配置。

若變數排列方式與總大小允許，多個較小的值類型變數可共用一個欄位。

例如，數個較小的整數或布林值可能可放在同一個欄位，而不必分占多個欄位。

Solidity 儲存布局文件說明變數、結構、陣列、繼承與打包方式如何影響欄位配置。

因此，變數順序可能改變合約所需的欄位數量。

但使用最小整數類型不一定更省成本。

EVM 通常以 256 位元字執行運算，因此較小整數類型可能需要額外遮罩或轉換操作。

當多個打包值通常會一起讀取或寫入時，打包的效益最明顯。

只更新打包欄位中的一個值，可能需要讀取整個欄位、修改部分字元，再將組合後的數值寫回。

對可升級合約而言，儲存布局也是相容性的一部分，因此部署後不應只為省 Gas 而重新排列既有狀態變數。

使用 constant 與 immutable 變數

編譯後永不變更的數值，在 Solidity 允許時通常應宣告為

。

在合約建構時選定、之後固定不變的數值，可宣告為

。

常數與不可變變數會避免一般持久儲存存取，因為其值會內嵌或儲存在合約程式碼中。

官方 Solidity 合約文件說明這些變數與一般狀態變數的差異。

常見候選值包括固定設定值、永久地址、數學常數，以及部署後不得變更的限制值。

若應用程式確實需要治理機制或其他授權流程更新數值，就不應將變數設為 immutable。

只為省 Gas 而移除必要彈性，日後可能造成更大的營運問題。

唯讀外部輸入使用 calldata

外部函式中不需修改的參數，通常可使用

資料位置。

Calldata 為唯讀，可避免在執行一開始就將完整輸入複製到記憶體。

Solidity 資料位置指南建議盡可能使用 calldata，因為這可避免複製且防止修改。

此技巧尤其適用於傳入外部函式的陣列、位元組序列、字串與結構。

合約必須修改資料或建立新的記憶體值時，則適合使用 memory。

開發者不應假設將函式參數從

改成較小整數，就一定能縮小 calldata 大小。

標準 ABI 編碼通常會將靜態值放入 32 位元組字中，較小類型還可能增加轉換或驗證工作。

應透過測量確認 Gas 節省，不要只根據原始碼中的類型名稱推斷。

縮減交易 Calldata

交易 calldata 中的每個位元組都會增加交易內含成本。

不必要的陣列、重複欄位、冗長文字字串與低效率編碼，都可能提高使用者交易成本。

有時可將重複的完整數值改為精簡識別碼，再由合約對應至已儲存的設定。

也可避免傳送合約能從現有狀態或交易發送者安全推導的資訊。

特定系統中，壓縮可能有幫助，但解壓縮本身會消耗 Gas，可能抵銷預期節省。

Pectra 已啟用 EIP-7623，為資料量大的交易設立較高的 Gas 下限。

對於攜帶大量資料、但 EVM 執行量相對較少的交易，Calldata 效率因此尤其重要。

開發者應比較精簡 calldata 的成本與解碼所需的額外執行量。

交易範圍狀態使用 Transient Storage

Transient storage 可讓合約儲存的數值在單筆交易中的內部呼叫期間持續可用，並在交易結束時自動清除。

Ethereum 透過 EIP-1153 導入

與 操作碼。

Transient storage 比持久儲存便宜，因為資料不會成為永久區塊鏈狀態的一部分。

常見用途是在單筆交易執行期間使用重入鎖。

目前的 Solidity 版本支援 transient 值類型狀態變數，前提是合約以 Cancun EVM 或更新的相容版本為目標。

不得將 transient storage 用於必須在後續交易中保留的資訊。

也必須仔細了解它在一般呼叫、委派呼叫及可組合合約中的行為。

Solidity transient storage 文件提醒，暫存狀態的有效範圍為單筆交易，且在不同呼叫類型下有特定的所有權行為。

在新實作經過完整測試與稽核前，開發者不應以 transient storage 取代已驗證的安全機制。

使用自訂錯誤取代冗長的回復字串

自訂錯誤是有效率且能回傳結構化失敗資訊的方法。

冗長的回復字串會納入部署位元組碼，並在條件失敗時產生編碼回傳資料。

自訂錯誤使用 4 位元組選擇器及任何已宣告參數，可減少部署大小與失敗路徑成本。

Solidity 自訂錯誤文件將自訂錯誤描述為方便且有效率的錯誤處理機制。

錯誤名稱與參數仍應清楚，讓錢包、開發者與監控系統能診斷問題。

移除所有有用的錯誤資訊，或許只能省下一點 Gas，卻會使失敗的加密貨幣交易更難調查。

最佳化迴圈與陣列處理

若迴圈次數取決於沒有嚴格上限、且可能持續擴大的陣列或儲存集合，成本可能非常高。

無上限的迴圈最終可能需要超過單筆交易可提供的 Gas，導致重要合約函式無法使用。

可行時，應將大型工作拆分為有明確上限的批次。

若迴圈反覆從儲存空間讀取陣列長度，有時可先將長度快取到本地變數。

若安全無虞，也可快取每次迭代使用的儲存值。

只有在能證明不會溢位時，開發者才可對迴圈計數器使用

運算。

現代 Solidity 編譯器已能最佳化數種常見迴圈模式，因此採用手動修改前應先進行效能測試。

將工作分散到多筆交易可提高可靠性，但合約必須安全追蹤進度，避免工作遭跳過、重複或重新排序。

避免重複的外部呼叫

呼叫其他合約會消耗 Gas，也會讓交易受到被呼叫合約執行行為的影響。

若安全呼叫一次即可取得所需數值，函式就應避免重複索取相同外部資訊。

有時可將數個相關操作合併成一次合約呼叫。

但批次處理會增加可能一起失敗的工作量，也可能產生更大的 calldata 負載。

外部呼叫也可能造成重入、回傳意外資料、消耗大量 Gas，或使整筆交易回復。

絕不能為了節省 Gas 而移除回傳值檢查或安全的呼叫處理方式。

開發者應判斷快取的外部數值在整個執行期間是否仍有效，以及外部系統是否能透過回呼改變該值。

適當時以事件取代儲存

事件會將資訊記錄在交易日誌中，供鏈下應用程式索引。

與將相同資訊儲存在合約狀態相比，使用事件通常成本較低。

活動紀錄、使用者介面通知、分析資料，以及未來智能合約執行不需讀取的紀錄，都適合使用事件。

事件不能取代會影響餘額、所有權、權限、債務、抵押品或其他合約行為的狀態。

一般 EVM 執行無法擷取歷史日誌。

如果系統只將重要帳務資訊存入事件，就必須依靠鏈下服務重建資料，且無法直接在鏈上強制執行。

事件參數也應妥善設計，因為索引主題與日誌資料的 Gas 成本和搜尋特性不同。

縮減合約部署大小

合約部署費用包括執行初始化邏輯與儲存執行時位元組碼。

未使用的函式、重複邏輯、冗長回復字串與內嵌資料都可能增加部署成本。

開發者應移除無效程式碼，且只需要大型函式庫一小部分時，避免匯入整個大型函式庫。

外部函式庫可減少多次部署時重複的位元組碼，但呼叫外部函式庫可能增加執行時成本與營運依賴。

部署許多相似合約實例時，工廠與 clone 模式可降低成本，因為多個實例可共用實作程式碼。

Proxy 模式可支援升級與重複部署，但也會增加委派呼叫開銷，並帶來儲存布局、治理與安全性上的重大考量。

Ethereum 透過 EIP-170 限制一般部署後執行時位元組碼大小；EIP-3860 則對初始化程式碼計量並設限。

只為符合大小上限而拆分程式碼，可能增加呼叫成本，因此應評估整個合約生命週期的架構。

指定正確的 EVM 版本

編譯器輸出會依選定的 EVM 目標版本而異。

若編譯器以較新 EVM 為目標，可能使用舊網路不支援的指令。

例如，Shanghai 透過 EIP-3855 導入

指令，能以更小且更便宜的指令將 0 推入堆疊。

Dencun 透過 EIP-5656 導入

，提供更有效率的記憶體複製方式。

若設定相容網路，現代編譯器可自動使用這些指令。

若目標網路尚未啟用相關協議升級，使用該升級編譯的合約可能無法部署或執行。

因此，建置系統應為每條目標鏈設定正確的 EVM 版本。

充分測試後再考慮存取清單

存取清單可列出交易預計存取的帳戶與儲存金鑰。

執行開始時，清單中的項目會視為暖存取，降低後續冷存取費用。

EIP-2930會對清單中的每個地址與儲存金鑰收費。

對於部分可預測的交易，準確的存取清單可能降低成本。

清單若不完整或不必要，可能會增加總費用，因為使用者須為效益過低或未使用的項目付費。

若確切執行路徑取決於持續變動的區塊鏈狀態，存取清單可能難以產生。

開發者應分別模擬有無存取清單的完整交易，不要假設預先載入狀態總是更便宜。

謹慎批次處理使用者操作

將多個操作合併為一筆交易，可避免多次支付基本交易開銷。

例如，應用程式可能提供整合流程，讓使用者核准並執行操作。

Pectra 已啟用 EIP-7702，讓外部擁有帳戶可將執行委派給智能合約程式碼，並支援批次處理與 Gas 贊助等錢包功能。

批次處理不會自動降低每部分執行成本，因為每個操作仍須完成必要的合約工作。

大型批次可能超出實際 Gas 上限、增加 calldata，或因其中一步失敗而使所有操作回復。

應用程式應定義是否允許部分完成，以及如何回報失敗的子操作。

應仔細檢查錢包授權與委派程式碼，因為批次系統可能取得對使用者資產的廣泛控制權。

適當時使用 Layer 2 網路

應用程式層級最佳化可減少消耗的 Gas 單位數；Layer 2 網路則可降低使用者為執行與資料支付的價格。

Rollup 會在 Ethereum 主網外處理活動，再將資料或證明發布回 Ethereum。

Dencun 透過 EIP-4844 導入攜帶 Blob 的交易，為 Rollup 提供暫時且更專用的資料通道。

Pectra 與 Fusaka 後續進一步擴充 Ethereum 的擴展與資料可用性能力。

目前的 Ethereum 建置者指南說明近期升級如何改變主網費用、帳戶功能與 Rollup 經濟模式。

部署至 Layer 2 網路並不代表不必最佳化合約，因為不必要的儲存與運算仍會提高使用者費用並降低容量。

選擇網路前，開發者也應評估跨鏈橋、提領、流動性、安全性與互通性需求。

非必要時避免使用內嵌組合語言

內嵌組合語言可讓開發者精確控制 EVM 操作，有時能降低 Gas。

但它也會移除或繞過 Solidity 的部分型別檢查、記憶體保護與高階安全功能。

簡短的組合語言程式可能難以讓審查者理解，且可能造成記憶體損毀、編碼錯誤或不安全的呼叫行為。

編譯器可能已能將一般 Solidity 最佳化成與手動實作同樣有效率的程式碼。

因此，組合語言應保留給經測量確認的效能瓶頸、特定密碼學、底層資料處理，或 Solidity 無法有效表達的功能。

每項組合語言最佳化都應搭配測試，將輸出與清楚的參考實作比較。

若組合語言控制代幣餘額、簽章、權限或外部呼叫，獨立安全審查尤其重要。

切勿為節省 Gas 犧牲安全性

若較便宜的智能合約可能導致使用者加密貨幣損失，就不算更好。

開發者不應只為省 Gas 而移除存取控制、輸入驗證、防重入保護、帳務準確性或其他安全屬性。

只有在所有可行條件下都能以數學方式證明不會溢位或下溢時，才應使用 unchecked 運算。

將多個變數壓縮成單一數值可節省儲存空間，但可能增加位元操作錯誤的機率。

使用 Proxy 可降低部署成本，卻會帶來升級權限與儲存衝突風險。

使用鏈下簽章可減少交易，但必須正確處理 Nonce、到期時間、網域分隔與重放保護。

評估每項最佳化時，除了 Gas 成本，也應考量可讀性、可稽核性、營運風險與後續維護。

常見的 Gas 最佳化錯誤

常見錯誤之一，是選用較小整數類型，卻沒有與其他值打包。

EVM 以 256 位元字運作，單獨使用較小類型本身不一定會降低執行成本。

另一個錯誤是，即使函式只需讀取 calldata，仍將全部資料複製到 memory。

第三個錯誤是只為追求退款而清除儲存資料，之後又計畫建立相同狀態。

第四個錯誤是對持續擴大的儲存陣列使用無上限迴圈。

第五個錯誤是未比較部署與執行表現，就選用高 runs 值。

第六個錯誤是在分析合約效能前就手寫組合語言。

第七個錯誤是編譯器或網路升級改變操作碼行為後，仍假設原有最佳化有效。

第八個錯誤是只測量成功交易，忽略成本高昂的回復路徑。

第九個錯誤是把較低的 Gas 估算當成兩種實作具備相同安全性與業務邏輯的證明。

如何建立 Gas 最佳化流程

可靠流程應先定義合約必須具備的行為與安全屬性。

團隊應先建立功能測試，再開始低階最佳化。

接著測量部署成本與每條重要交易路徑的 Gas 用量。

透過效能分析找出成本最高的儲存寫入、迴圈、calldata 輸入與外部呼叫。

開發者可簡化架構、減少狀態變更、選擇適當資料位置，並啟用經測試的編譯器最佳化設定。

每項變更都應與原始版本比較測量結果，並檢查是否引入新的安全風險。

專案應保留 Gas 回歸測試，避免後續開發在未察覺的情況下抵銷節省效果。

正式部署位元組碼應使用固定版本的編譯器、經驗證的設定、正確 EVM 目標與已審查的相依版本編譯。

即使高價值加密貨幣合約通過內部測試，也應接受獨立安全稽核。

常見問題

最好的 Gas 最佳化技術是什麼？

最有效的方式通常是減少持久儲存操作，並簡化每筆交易所執行的鏈上工作。

Solidity 最佳化器一定會降低 Gas 嗎？

不一定。某些設定可能降低執行時 Gas，卻提高部署成本，因此開發者應測試合約的完整生命週期。

最佳化器的 runs 設定代表什麼？

它告訴編譯器開發者預期執行時程式碼會執行多少次，並影響部署大小與重複執行成本之間的取捨。

Storage 比 memory 貴嗎？

是。持久儲存通常昂貴得多，因為交易結束後資料仍會保留在區塊鏈狀態中。

Calldata 比 memory 便宜嗎？

唯讀外部輸入使用 calldata 可能較便宜，因為合約不必先將全部資料複製到記憶體。

較小的整數類型一定能節省 Gas 嗎？

不一定。當多個值能打包至同一個儲存欄位時，效益通常較明顯；單獨使用的小整數可能需要額外轉換操作。

開發者為什麼要快取儲存值？

若數值維持不變且可安全從堆疊或記憶體重複使用，快取可避免重複讀取儲存資料。

什麼是 Transient Storage？

Transient storage 是交易範圍內的 EVM 儲存資料，會自動清除，可用於重入鎖等低成本暫時狀態。

自訂錯誤比回復字串便宜嗎？

通常是。自訂錯誤使用精簡選擇器與編碼參數，不必儲存並回傳冗長文字，因此 Gas 效率較高。

事件可以取代合約儲存嗎？

只有在未來智能合約執行不需讀取或強制執行該資訊時，事件才能取代儲存。

刪除儲存資料會退還所有 Gas 成本嗎？

不會。清除儲存資料的退款有限，且受協議層級 Gas 退款上限限制。

開發者應使用 unchecked 運算節省 Gas 嗎？

只有在能證明不可能溢位或下溢，且安全理由已記錄並測試時，才應使用 unchecked 運算。

批次交易一定能節省 Gas 嗎？

不一定。批次處理可減少重複交易開銷，但也可能增加 calldata、執行複雜度與整批失敗的風險。

Layer 2 網路能取代合約最佳化嗎？

不能。較低的網路費用可降低使用者成本，但低效率合約在同一網路上仍會浪費執行容量，且比最佳化合約更昂貴。

存取清單一定能降低 Gas 嗎？

不一定。存取清單項目本身有成本；項目不準確或不必要時，可能增加費用。

內嵌組合語言一定比較省 Gas 嗎？

不一定。編譯器可能已產生同樣有效率的程式碼，而不安全的組合語言可能造成嚴重安全與維護問題。

開發者如何測量 Gas 用量？

可使用編譯器估算、Gas 快照、自訂交易測試、執行追蹤與效能分析工具。

網路升級後，Gas 成本為什麼可能改變？

Ethereum 升級可能新增操作碼、重新定價既有操作、改變 calldata 規則，或導入更有效率的儲存與記憶體功能。

Gas 最佳化可以避免高額網路費用嗎？

它能減少 Gas 用量，但無法阻止許多使用者競逐區塊空間時市場 Gas 價格上升。

成本最低的合約一定最好嗎？

不一定。正確性、安全性、可讀性與可維護性，比小幅節省 Gas 更重要。

結論

Gas 最佳化技術可減少加密貨幣智能合約所需的運算、儲存、calldata 與部署資源。

最大幅度的節省通常來自減少持久儲存寫入、快取安全的儲存讀取、選擇正確資料位置、縮減不必要的 calldata，以及避免重複外部呼叫。

現代 Solidity 編譯器可以自動最佳化位元組碼，但應透過貼近實際情境的測量選擇最佳化器設定，而非憑猜測決定。

Transient storage、

、、委派帳戶程式碼與更新後的 calldata 定價等 Ethereum 新功能，已改變開發者進行最佳化的方式。

開發者應指定正確的 EVM 版本，並確保編譯器、測試與協議規則知識保持更新。

變數打包、自訂錯誤、有上限的迴圈、批次處理、事件、函式庫與部署至 Layer 2 等技術，符合應用程式設計時可降低成本。

存取清單、Proxy、內嵌組合語言、unchecked 運算與壓縮儲存都需格外謹慎，因為微小的 Gas 效益可能帶來顯著複雜度或風險。

每項最佳化都應評估部署、成功執行、失敗路徑與合約長期使用情況。

絕不能只為降低 Gas 報告數值而移除安全檢查。

最佳的 Gas 最佳化策略，是只執行安全且可驗證的加密貨幣操作所必需的鏈上工作。