有個(gè)朋友拿合約代碼來找我說他把游戲里的專屬道具做成了代幣結(jié)果玩家發(fā)現(xiàn)同一件限量裝備能被拆分出0.5個(gè)還把“稀有度”直接拆沒了。另一個(gè)新手問得更多ETH到底算不算一個(gè)ERC20代幣這倆問題表面上是使用姿勢(shì)不對(duì)根子其實(shí)是一樣的——很多人把Coin和Token混為一談也沒想清楚ERC20和ERC721各自對(duì)應(yīng)的賬本邏輯。這篇就把這塊掰開揉碎Coin和Token的區(qū)別、ERC20與ERC721的設(shè)計(jì)邏輯、Solidity 0.8.4之后的自定義錯(cuò)誤機(jī)制以及合約繼承怎么把這些東西組織成一個(gè)能上線的項(xiàng)目。適合已經(jīng)能寫簡(jiǎn)單合約、但想真正讀懂OpenZeppelin源碼的開發(fā)者純新人的話把這四個(gè)概念當(dāng)成進(jìn)入智能合約世界的四塊墊腳石也完全夠用。1. Coin與Token為什么ETH不是ERC20代幣1.1 協(xié)議記賬與合約記賬Coin和Token在中文社區(qū)經(jīng)常被混著叫大家都說“代幣”但技術(shù)上它們是兩層?xùn)|西。Coin是鏈的原生資產(chǎn)。拿以太坊來說ETH的余額由協(xié)議層維護(hù)存在賬戶狀態(tài)里由狀態(tài)樹統(tǒng)一管理。你轉(zhuǎn)賬ETH本質(zhì)是協(xié)議在執(zhí)行一個(gè)“賬戶狀態(tài)變更”操作根本不需要經(jīng)過某個(gè)合約的代碼邏輯。所以Solidity里沒有任何一個(gè)合約能直接修改另一個(gè)地址的原生余額你只能通過轉(zhuǎn)賬動(dòng)作讓協(xié)議層去改。Token則是部署在鏈上的合約里記錄的數(shù)字。合約內(nèi)部用一個(gè)mapping記著“誰誰誰有多少個(gè)Token”比如mapping(address uint256) public balanceOf。你轉(zhuǎn)Token是調(diào)用一個(gè)合約函數(shù)修改的是合約自己的存儲(chǔ)空間。合約定多少總量、能不能增發(fā)、能不能銷毀完全由合約代碼說了算。理解這一層差異特別重要。為什么Coin能付gas、能參與協(xié)議層的質(zhì)押因?yàn)樗菂f(xié)議資產(chǎn)。為什么有些Token只能在特定應(yīng)用里流通因?yàn)樗皇悄莻€(gè)合約里的一條賬本記錄。1.2 零地址和WETHCoin進(jìn)入Token生態(tài)的橋很多交易協(xié)議在處理“ETH兌換某個(gè)ERC20代幣”時(shí)會(huì)用一個(gè)約定用零地址address(0)代表ETH。為什么因?yàn)镋TH本身不是ERC20沒有balanceOf、transfer這些標(biāo)準(zhǔn)函數(shù)無法塞進(jìn)通用的代幣路由邏輯里。為了解決這個(gè)問題就有了WETHWrapped Ether。WETH9合約做的事情很直白你調(diào)用deposit()并附帶ETH合約按照1:1給你鑄造WETH你調(diào)用withdraw(amount)合約銷毀對(duì)應(yīng)WETH并把ETH還給你。這樣ETH就被“包裝”成了標(biāo)準(zhǔn)ERC20可以參與DEX的流動(dòng)性池、借貸抵押等所有ERC20生態(tài)。這就引出一個(gè)很常見的現(xiàn)實(shí)坑有人直接把ETH轉(zhuǎn)給某個(gè)合約地址以為對(duì)方會(huì)自動(dòng)收到一筆“代幣余額”。實(shí)際上合約是否能接收ETH取決于它有沒有定義receive()或者fallback()回退函數(shù)。很多只處理ERC20的合約壓根沒寫支付函數(shù)ETH轉(zhuǎn)過去交易直接失敗也有少數(shù)合約能收ETH但沒有提供任何提取入口資金就變成了一筆永遠(yuǎn)沉睡在合約里的余額。順帶說一句ERC20代幣直接轉(zhuǎn)到不兼容的合約地址也會(huì)出現(xiàn)類似問題Token進(jìn)賬了但合約里沒有邏輯去操作這筆余額就成了死幣。集成第三方協(xié)議時(shí)要先確認(rèn)對(duì)方是否有對(duì)應(yīng)的“提現(xiàn)”或“退款”路徑。1.3 Coin與Token的關(guān)鍵對(duì)比維度Coin原生資產(chǎn)Token合約代幣記賬方協(xié)議層賬戶狀態(tài)合約storage轉(zhuǎn)賬方式協(xié)議轉(zhuǎn)賬調(diào)用合約函數(shù)存在形式鏈本身的資產(chǎn)合約里的賬本記錄能否付gas能通常不能發(fā)行規(guī)則由共識(shí)與協(xié)議規(guī)則決定由合約代碼決定化名地址零地址常代表ETH有實(shí)際合約地址實(shí)際操作中判斷一個(gè)資產(chǎn)是Coin還是Token最簡(jiǎn)單的方式就是看它有沒有合約地址。沒有合約地址、由協(xié)議層直接維護(hù)余額的是Coin需要依賴合約邏輯流轉(zhuǎn)的是Token。這個(gè)判斷在做鏈上數(shù)據(jù)解析、錢包開發(fā)或者DEX路由集成時(shí)幾乎每天都會(huì)用到。2. ERC20與ERC721兩套賬本兩種所有權(quán)2.1 ERC20的“余額授權(quán)”模型ERC20解決的是同質(zhì)化資產(chǎn)的記賬問題。同質(zhì)化是什么意思你手里的1個(gè)A代幣和我手里的1個(gè)A代幣完全等價(jià)可以互相替換可以拆分可以加總。最簡(jiǎn)ERC20的核心數(shù)據(jù)結(jié)構(gòu)其實(shí)就這幾樣mapping(address uint256) public balanceOf; mapping(address mapping(address uint256)) public allowance; uint256 public totalSupply; event Transfer(address indexed from, address indexed to, uint256 amount); event Approval(address indexed owner, address indexed spender, uint256 amount);balanceOf記錄每個(gè)地址的余額allowance記錄“A授權(quán)B可以動(dòng)用多少A的余額”totalSupply是總量。標(biāo)準(zhǔn)接口里的approve和transferFrom就是圍繞這兩個(gè)mapping設(shè)計(jì)的。為什么需要授權(quán)而不是每次都由本人轉(zhuǎn)賬因?yàn)楹芏鄨?chǎng)景下合約需要代替用戶扣款。你去DEX用代幣換另一個(gè)代幣鏈上執(zhí)行鏈下訂單實(shí)際是由兌換合約調(diào)用transferFrom從你的余額里扣錢再轉(zhuǎn)給交易對(duì)手。如果只能本人轉(zhuǎn)賬DEX合約就永遠(yuǎn)無法執(zhí)行“用戶委托交易”了。這里有三個(gè)實(shí)際踩過的坑值得記住授權(quán)競(jìng)態(tài)問題。approve把授權(quán)額度從5改成3本質(zhì)是兩次獨(dú)立交易中間如果有人搶先調(diào)用transferFrom你的額度變化可能不符合預(yù)期。慣例做法是先approve(spender, 0)再approve(spender, value)。無限授權(quán)。很多DEX會(huì)讓用戶授權(quán)一個(gè)超大額度比如type(uint256).max合約一旦被攻擊用戶余額可能被一次性掏空?，F(xiàn)在很多協(xié)議改用臨時(shí)授權(quán)或額度遞減但老一代合約普遍是無限授權(quán)。返回值不一致。標(biāo)準(zhǔn)ERC20要求transfer和transferFrom返回bool但USDT這類早期代幣沒有返回值直接讓很多新手合約遇到“交易回滾”。所以實(shí)際項(xiàng)目里最好用SafeERC20這類封裝庫(kù)它會(huì)檢查返回值。2.2 ERC721的“歸屬批準(zhǔn)”模型ERC721處理的是非同質(zhì)化資產(chǎn)每個(gè)tokenId代表一個(gè)獨(dú)一無二的物品。它不記錄“你有多少個(gè)同款”而是記錄“這個(gè)特定物品歸誰”。核心數(shù)據(jù)結(jié)構(gòu)長(zhǎng)這樣mapping(uint256 address) private _owners; mapping(address uint256) private _balances; mapping(uint256 address) private _tokenApprovals; mapping(address mapping(address bool)) private _operatorApprovals;_owners是核心tokenId到持有人的映射它決定了一項(xiàng)資產(chǎn)的歸屬。_balances存的是“某人持有多少個(gè)不同的NFT”而不是NFT的數(shù)量可以拆分。_tokenApprovals允許持有人針對(duì)某個(gè)特定tokenId授權(quán)他人轉(zhuǎn)移_operatorApprovals則是一次性授權(quán)某個(gè)操作者管理持有人全部NFT。ERC721里有一個(gè)關(guān)鍵安全點(diǎn)safeTransferFrom。和ERC20的transfer不同NFT轉(zhuǎn)到一個(gè)合約地址之前接收合約必須實(shí)現(xiàn)onERC721Received接口并返回正確的函數(shù)選擇器0x150b7a02否則轉(zhuǎn)賬回滾。這是為了防止NFT被意外發(fā)送到一個(gè)沒有處理能力的合約里導(dǎo)致資產(chǎn)永久鎖死。用ERC20的思路寫NFT最容易犯的錯(cuò)就是把每個(gè)NFT當(dāng)成一個(gè)可拆分的小數(shù)來處理。ERC721沒有decimals概念一個(gè)tokenId就是一件完整資產(chǎn)。你沒法把一件NFT轉(zhuǎn)0.5個(gè)出去這恰恰是它的設(shè)計(jì)價(jià)值資產(chǎn)不可拆所有權(quán)分界清晰。2.3 何時(shí)用ERC20何時(shí)用ERC721對(duì)比項(xiàng)ERC20ERC721代幣單位可拆分、有decimals不可拆分、tokenId唯一記賬核心balanceOf allowanceownerOf approvals轉(zhuǎn)賬語義轉(zhuǎn)移數(shù)量轉(zhuǎn)移某個(gè)具體資產(chǎn)典型場(chǎng)景積分、支付、治理、流動(dòng)性藏品、票據(jù)、身份、裝備存儲(chǔ)開銷一個(gè)地址一行余額每個(gè)資產(chǎn)多行狀態(tài)選型時(shí)我會(huì)先問自己這東西能被拆分成0.5個(gè)還合理嗎合理用ERC20不合理用ERC721。如果是一類資產(chǎn)、每個(gè)個(gè)體有共性但又有差異比如游戲里同一種皮膚但有不同的編號(hào)那么ERC721更合適如果你的業(yè)務(wù)是積分、點(diǎn)數(shù)、治理投票權(quán)ERC20是自然選擇。還有介于兩者之間的場(chǎng)景比如半同質(zhì)化的游戲道具批量生成可以看ERC1155但這篇文章不展開。3. 自定義錯(cuò)誤機(jī)制從Error(string)到Panic再到自定義error3.1 EVM里的錯(cuò)誤長(zhǎng)什么樣Solidity里的異常處理表面上就是require、revert、assert這幾個(gè)關(guān)鍵字但到了EVM層面它們產(chǎn)生的數(shù)據(jù)是完全不同的。require(false, Insufficient balance)底層會(huì)觸發(fā)一個(gè)Error(string)類型的revert數(shù)據(jù)鏈上編碼是函數(shù)選擇器0x08c379a0后面跟著ABI編碼的字符串偏移量、字符串長(zhǎng)度、字符串內(nèi)容右填充到32字節(jié)倍數(shù)所以哪怕是一條很短的錯(cuò)誤消息revert數(shù)據(jù)也會(huì)有上百字節(jié)。assert(false)以及0.8.0之后的某些自動(dòng)檢查失敗會(huì)觸發(fā)Panic(uint256)類型的數(shù)據(jù)選擇器是0x4e487b71后面跟一個(gè)錯(cuò)誤碼。常用錯(cuò)誤碼有幾個(gè)0x01是assert條件不滿足0x11是算術(shù)溢出或下溢0x12是除以00x32是數(shù)組下標(biāo)越界。Solidity 0.8.0之后整數(shù)的溢出和下溢默認(rèn)會(huì)回滾這就是為什么你明明沒有寫assert卻在某些算術(shù)錯(cuò)誤時(shí)看到Panic(0x11)。這是編譯器自動(dòng)插入的檢查。很多人以為require失敗會(huì)扣掉所有g(shù)as其實(shí)不是這樣。revert發(fā)生時(shí)EVM會(huì)把當(dāng)前調(diào)用棧里剩余的gas返還給調(diào)用者已經(jīng)消耗掉的gas不會(huì)返還。也就是說revert不會(huì)“吞掉全部gas”真正影響成本的是你已經(jīng)執(zhí)行的運(yùn)算以及你需要打包到交易數(shù)據(jù)或返回給調(diào)用者的錯(cuò)誤數(shù)據(jù)長(zhǎng)度。3.2 error關(guān)鍵字的正確打開方式Solidity 0.8.4引入了自定義錯(cuò)誤語法很簡(jiǎn)潔error NotOwner(uint256 tokenId); error InsufficientBalance(uint256 available, uint256 required); function withdraw(uint256 amount) external view { uint256 balance balanceOf[msg.sender]; if (balance amount) { revert InsufficientBalance(balance, amount); } // 繼續(xù)業(yè)務(wù)邏輯 }自定義錯(cuò)誤沒有字符串它的revert數(shù)據(jù)只有“錯(cuò)誤簽名哈希的前4字節(jié)”加“按ABI編碼的參數(shù)”。拿NotOwner(uint256)來說無參數(shù)的自定義錯(cuò)誤只有4字節(jié)帶兩個(gè)uint256參數(shù)的也就是46468字節(jié)。對(duì)比一下前面Error(string)動(dòng)輒上百字節(jié)的載荷區(qū)別很明顯。這里省gas的原理不是“錯(cuò)誤觸發(fā)的瞬間能返還更多gas”而是錯(cuò)誤數(shù)據(jù)更短調(diào)用者和節(jié)點(diǎn)處理時(shí)消耗的gas更少錯(cuò)誤簽名作為編譯期常量不會(huì)像字符串那樣被完整寫到合約字節(jié)碼里部署合約更便宜高頻路徑上比如一個(gè)資金池的存取款每次失敗都省幾十到幾百gas積累起來是實(shí)打?qū)嵉某杀緝?yōu)化。所以在0.8.4之后的合約里我的習(xí)慣是常規(guī)校驗(yàn)用require需要給調(diào)用者清晰錯(cuò)誤信息、希望鏈上監(jiān)控更精準(zhǔn)的地方一律用自定義錯(cuò)誤。assert只在“絕對(duì)不變量”的地方使用比如assert(totalSupply sumOfAllBalances)它更多是給審計(jì)工具和開發(fā)者看的不變量聲明。3.3 鏈上觀察、解析與try/catch自定義錯(cuò)誤的一個(gè)實(shí)際問題是它比require(字符串)更難在瀏覽器上直接讀懂。你打開區(qū)塊鏈瀏覽器看一個(gè)失敗交易可能只看到一堆十六進(jìn)制數(shù)據(jù)不顯示具體錯(cuò)誤內(nèi)容。好在我可以用Foundry或者ethers.js做解碼。cast命令里cast sig Error(string) # 0x08c379a0 cast sig Panic(uint256) # 0x4e487b71 cast sig NotOwner(uint256)然后解析revert字節(jié)第一步先看前4字節(jié)是不是某個(gè)已知錯(cuò)誤的選擇器。如果自定義錯(cuò)誤帶參數(shù)還要按ABI把參數(shù)解出來。ethers.js里你可以引入合約的ABI讓工具自動(dòng)還原成可讀的錯(cuò)誤文本。在合約內(nèi)部如果想捕獲外部調(diào)用的錯(cuò)誤Solidity提供了try/catch。注意它的限制只能捕獲外部調(diào)用、address.call或合約實(shí)例調(diào)用觸發(fā)的revert不能捕獲當(dāng)前合約內(nèi)部自己的錯(cuò)誤。語法上支持多個(gè)分支try pool.swap(...) returns (uint256 amountOut) { // 成功路徑 } catch Error(string memory reason) { // 捕獲 require/revert(...) } catch (bytes memory reason) { // 捕獲 Panic 或自定義錯(cuò)誤 if (bytes4(reason) MyError.selector) { // 處理自定義錯(cuò)誤 } }這里有個(gè)容易被忽略的點(diǎn)不要試圖把敏感信息放進(jìn)錯(cuò)誤參數(shù)里。錯(cuò)誤數(shù)據(jù)最終會(huì)留在鏈上任何人通過交易日志和失敗狀態(tài)都能看到。把用戶的完整私密數(shù)據(jù)或者別人的隱私字段寫進(jìn)error參數(shù)等于公開展示。4. 合約繼承把共享邏輯拆成基類而不是復(fù)制粘貼4.1 繼承解決什么問題合約繼承和面向?qū)ο罄锏睦^承很像本質(zhì)是代碼復(fù)用和分層抽象。如果你打開OpenZeppelin的合約庫(kù)會(huì)發(fā)現(xiàn)幾乎不用“復(fù)制粘貼”這套土辦法。用到權(quán)限就is Ownable用到暫停機(jī)制就is Pausable發(fā)一個(gè)代幣就繼承ERC20。舉一個(gè)最常用的例子contract MyToken is ERC20, Ownable { constructor(address initialOwner) ERC20(MyToken, MTK) Ownable(initialOwner) {} }一行is ERC20整個(gè)標(biāo)準(zhǔn)代幣的函數(shù)和狀態(tài)變量totalSupply、balanceOf、approve、transferFrom等全部復(fù)用。一行is Ownable立刻有了owner、onlyOwner修飾符、transferOwnership函數(shù)。繼承的核心價(jià)值就是你不需要重新實(shí)現(xiàn)一個(gè)輪子只需要站在基類的能力之上增加業(yè)務(wù)邏輯。但繼承也帶來一個(gè)問題狀態(tài)變量和函數(shù)不是“復(fù)制”到子合約而是被編譯進(jìn)同一個(gè)合約的存儲(chǔ)布局里?；惖臓顟B(tài)變量按照既定順序排在前面子類狀態(tài)變量排在后面。這個(gè)順序一旦在升級(jí)中被打亂現(xiàn)有數(shù)據(jù)就會(huì)在存儲(chǔ)槽上錯(cuò)位讀出來全是垃圾。4.2 virtual、override、abstract、interface怎么配合Solidity里一個(gè)函數(shù)默認(rèn)情況下不允許被重寫必須顯式聲明virtual。子類重寫父類的函數(shù)時(shí)必須用override標(biāo)注。如果同時(shí)重寫了多個(gè)基類的同名函數(shù)要寫成override(A, B)?？匆粋€(gè)典型的抽象層級(jí)abstract contract Base { function greet() public pure virtual returns (string memory) { return base; } } contract Child is Base { function greet() public pure override returns (string memory) { return child; } }abstract合約表示“這個(gè)合約不完整”它可以有未實(shí)現(xiàn)的函數(shù)因此不能直接部署只能被子合約繼承后補(bǔ)全。interface的約束更強(qiáng)不能有任何狀態(tài)變量不能有構(gòu)造函數(shù)所有函數(shù)都只有簽名沒有實(shí)現(xiàn)可以定義事件和自定義錯(cuò)誤。什么時(shí)候用interface什么時(shí)候用abstract我的經(jīng)驗(yàn)是對(duì)外面向協(xié)議的交互比如IAMCALL的調(diào)用約定用interface因?yàn)榻涌谔烊贿m合定義調(diào)用邊界對(duì)內(nèi)部復(fù)用、已經(jīng)有部分實(shí)現(xiàn)的邏輯用abstract基類比如Ownable、Pausable這類包含狀態(tài)和方法的模塊。OpenZeppelin很多模塊其實(shí)是contract而不是interface原因就是它需要持有自己的存儲(chǔ)變量。繼承還有一個(gè)語法細(xì)節(jié)基類構(gòu)造函數(shù)帶參數(shù)時(shí)參數(shù)寫在繼承列表里或子類構(gòu)造函數(shù)里。上面例子里Ownable(initialOwner)就是子類構(gòu)造時(shí)向基類傳參的寫法?；悩?gòu)造函數(shù)的執(zhí)行順序遵循線性化規(guī)則最基類的構(gòu)造函數(shù)會(huì)先執(zhí)行之后才是更派生的部分。4.3 多重繼承與組合的取舍Solidity支持多重繼承用的時(shí)候要小心。不同基類如果有同名函數(shù)子類必須顯式重寫并聲明override(Base1, Base2)。調(diào)用super時(shí)會(huì)按C3線性化順序找到“下一個(gè)同名實(shí)現(xiàn)”。這里有兩個(gè)真實(shí)教訓(xùn)第一繼承列表的順序會(huì)影響存儲(chǔ)布局。contract X is A, B和contract X is B, AA、B的狀態(tài)變量在存儲(chǔ)槽里的相對(duì)順序可能不同。如果你在做可升級(jí)合約不同版本之間哪怕只是交換了繼承順序也可能導(dǎo)致舊數(shù)據(jù)處理錯(cuò)位。升級(jí)時(shí)不要隨意改繼承結(jié)構(gòu)。第二不要在基類構(gòu)造函數(shù)里調(diào)用會(huì)被子類重寫的函數(shù)。原因很簡(jiǎn)單構(gòu)造函數(shù)執(zhí)行時(shí)子類的狀態(tài)變量還沒初始化動(dòng)態(tài)分發(fā)不會(huì)走到子類重寫版本你會(huì)拿到一個(gè)“半初始化”狀態(tài)。我在早期合約里就犯過這個(gè)錯(cuò)基類構(gòu)造函數(shù)初始化一個(gè)值結(jié)果子類重寫后讀取到的是默認(rèn)值排查了很久。繼承和組合怎么選單一的小工具模塊用組合更直觀比如合約內(nèi)部持有另一個(gè)合約實(shí)例通過地址調(diào)用。但以太坊合約在存儲(chǔ)和Gas上有天然限制如果大量同類合約都要復(fù)用同一套復(fù)雜邏輯繼承在代碼簡(jiǎn)潔性和部署成本上更有優(yōu)勢(shì)?，F(xiàn)實(shí)里OpenZeppelin之所以被廣泛使用就是因?yàn)榇蠹壹s定好了同一個(gè)繼承結(jié)構(gòu)審計(jì)團(tuán)隊(duì)看代碼也更快。5. 拉到一起一個(gè)同時(shí)用上四個(gè)機(jī)制的收藏品合約5.1 完整示例合約下面這個(gè)合約把前面四個(gè)知識(shí)點(diǎn)串起來繼承了ERC721和Ownable引入了自定義錯(cuò)誤所有外部校驗(yàn)都沒有用require字符串// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import {ERC721} from openzeppelin/contracts/token/ERC721/ERC721.sol; import {Ownable} from openzeppelin/contracts/access/Ownable.sol; contract GameItem is ERC721, Ownable { uint256 public nextTokenId; error NotOwner(uint256 tokenId); error CharacterAlreadyMinted(uint256 characterId); mapping(uint256 bool) private _characterMinted; constructor() ERC721(GameItem, GIT) Ownable(msg.sender) {} function mintItem(uint256 characterId) external onlyOwner returns (uint256) { if (_characterMinted[characterId]) { revert CharacterAlreadyMinted(characterId); } _characterMinted[characterId] true; uint256 tokenId nextTokenId; _mint(msg.sender, tokenId); return tokenId; } function burnItem(uint256 tokenId) external { if (ownerOf(tokenId) ! msg.sender) { revert NotOwner(tokenId); } _burn(tokenId); } }合約的邏輯很簡(jiǎn)單管理員鑄造跟隨某個(gè)角色I(xiàn)D的唯一NFT角色I(xiàn)D不能重復(fù)鑄造只有NFT持有人才能銷毀自己的物品。這里繼承Ownable省去了手寫權(quán)限管理繼承ERC721則完整獲得了標(biāo)準(zhǔn)接口。CharacterAlreadyMinted和NotOwner把錯(cuò)誤原因帶上了具體參數(shù)鏈上監(jiān)控一看就知道是哪個(gè)角色I(xiàn)D沖突、哪個(gè)tokenId不是你的。順便說一句OpenZeppelin 5.0之后的Ownable構(gòu)造函數(shù)要求傳入初始o(jì)wner不能無參調(diào)用這是版本升級(jí)帶來的變化。如果你用舊教程的寫法Ownable()編譯會(huì)直接報(bào)錯(cuò)。5.2 用一次失敗交易驗(yàn)證錯(cuò)誤編碼把這個(gè)合約部署到測(cè)試網(wǎng)然后用一個(gè)非owner地址調(diào)用mintItem(1)交易回滾后你可以拿到原始revert字節(jié)。用Foundry模擬時(shí)大致是cast call contract mintItem(uint256) 1 --rpc-url rpc --from nonOwner結(jié)果里如果只看到CharacterAlreadyMinted(uint256)對(duì)應(yīng)的選擇器和參數(shù)說明自定義錯(cuò)誤的路徑生效了。你也可以用cast sig先算出錯(cuò)誤簽名再對(duì)著revert數(shù)據(jù)核對(duì)cast sig CharacterAlreadyMinted(uint256)這并不僅限于測(cè)試工具鏈。生產(chǎn)環(huán)境里你可以對(duì)已知錯(cuò)誤的選擇器做鏈上監(jiān)控一旦某個(gè)地址頻繁觸發(fā)NotOwner(uint256)就能推斷出有人在嘗試操作不屬于自己的NFT提前察覺攻擊或誤操作。5.3 四個(gè)機(jī)制配合使用時(shí)的實(shí)際取舍把上面這些機(jī)制放在同一個(gè)項(xiàng)目里的經(jīng)驗(yàn)我大致是這幾條。先判斷資產(chǎn)是Coin還是Token再?zèng)Q定要不要寫合約。純Coin場(chǎng)景往往只需要處理協(xié)議層轉(zhuǎn)賬不需要發(fā)一個(gè)標(biāo)準(zhǔn)代幣。選標(biāo)準(zhǔn)時(shí)不要貪多。能用ERC20解決的問題不要上ERC721能用ERC721解決的問題不要硬套ERC1155。每多一個(gè)標(biāo)準(zhǔn)就多一層賬本和權(quán)限設(shè)計(jì)。自定義錯(cuò)誤優(yōu)先于require字符串。但也不要為了“省gas”把所有校驗(yàn)都改成error很多只出現(xiàn)一次的地方用require可讀性反而高。原則是高頻失敗路徑和需要帶參數(shù)的錯(cuò)誤用error一次性簡(jiǎn)單校驗(yàn)用require。繼承結(jié)構(gòu)是架構(gòu)決策。能繼承標(biāo)準(zhǔn)庫(kù)就繼承能組合邏輯就不隨意擴(kuò)繼承樹。在升級(jí)場(chǎng)景里保持繼承順序穩(wěn)定甚至比函數(shù)實(shí)現(xiàn)穩(wěn)定更重要。最后再分享一個(gè)日常習(xí)慣在合約里定義error的時(shí)候我會(huì)把事件日志也一并想好。錯(cuò)誤負(fù)責(zé)拒絕事件負(fù)責(zé)記錄歷史。兩者配合鏈路追蹤才能又快又準(zhǔn)。如果你也正在寫自己的第一個(gè)Web3項(xiàng)目建議就從這四個(gè)概念出發(fā)先不做復(fù)雜業(yè)務(wù)把賬本、錯(cuò)誤和繼承的邊界徹底跑通再去碰更花哨的玩法。