1. 一次編譯失敗引出的問題所有權(quán)究竟在約束什么很多人第一次接觸 Rust 所有權(quán)系統(tǒng)都是被一段看起來毫無問題的代碼打臉的。我當(dāng)年的場(chǎng)景是這樣的寫了個(gè)函數(shù)把String傳進(jìn)去處理處理完還想在外面繼續(xù)用它編譯器直接甩出一行value borrowed here after move我當(dāng)時(shí)的第一反應(yīng)是這語(yǔ)言怎么連個(gè)字符串都不讓人好好用。后來才明白那條報(bào)錯(cuò)不是刁難而是所有權(quán)系統(tǒng)在替我提前擋住一次潛在的內(nèi)存錯(cuò)誤——同樣的邏輯放到手動(dòng)管理內(nèi)存的環(huán)境里可能就是一次 double free 或者懸垂指針跑一百次掛一次排查三天找不到原因。這篇筆記想聊清楚三件事Rust 所有權(quán)系統(tǒng)在內(nèi)存層面到底做了什么、它憑什么能在沒有運(yùn)行時(shí)垃圾回收的前提下保證內(nèi)存安全、以及落到實(shí)際編碼里怎么把這套規(guī)則用順手而不是被它牽著走。適合已經(jīng)能寫幾行 Rust、被借用檢查器反復(fù)教育過但還沒建立起完整心智模型的讀者也適合從其他語(yǔ)言轉(zhuǎn)過來、想搞清楚零成本抽象在內(nèi)存管理上具體指什么的人。下面的內(nèi)容會(huì)涉及一些棧和堆的底層細(xì)節(jié)但不需要你懂匯編能看懂變量在內(nèi)存里大概長(zhǎng)什么樣就夠了。1.1 String 在內(nèi)存里的真實(shí)樣子要理解 move先得看清楚一個(gè)String到底占多少地方。在 64 位平臺(tái)上String由三個(gè)字段組成一個(gè)指向堆內(nèi)存的指針ptr8 字節(jié)、一個(gè)表示當(dāng)前長(zhǎng)度的len8 字節(jié)、一個(gè)表示已分配容量的capacity8 字節(jié)。這三個(gè)字段本身存放在棧上合計(jì) 24 字節(jié)真正裝字符的那塊緩沖區(qū)在堆上由分配器管理。這個(gè)結(jié)構(gòu)決定了后面所有行為的基調(diào)棧上的那 24 字節(jié)是描述符堆上的緩沖區(qū)才是實(shí)體。當(dāng)你寫下let s2 s1;的時(shí)候Rust 做的事情是把這 24 字節(jié)按位復(fù)制給s2然后立刻把s1標(biāo)記為不可用。注意堆上那塊緩沖區(qū)一次都沒有被復(fù)制也沒有被重新分配。這就是所謂 move 的真相——它不是搬家而是過戶。fn main() { let s1 String::from(hello); let s2 s1; // 24 字節(jié)的描述符被復(fù)制s1 失效 println!({}, s2); // 正常 // println!({}, s1); // 去掉注釋就報(bào)錯(cuò)borrow of moved value }為什么非要讓s1失效因?yàn)槿绻试S兩個(gè)描述符同時(shí)指向同一塊堆內(nèi)存那么當(dāng)它們各自離開作用域時(shí)都會(huì)嘗試釋放這塊內(nèi)存第二次釋放就是操作已釋放的內(nèi)存——這就是經(jīng)典的 double free。C 里拷貝構(gòu)造和析構(gòu)的配合稍微寫錯(cuò)一點(diǎn)就會(huì)踩這個(gè)坑Rust 選擇在編譯期直接把這條路堵死同一塊堆內(nèi)存同一時(shí)刻只能有一個(gè)所有者。1.2 三條規(guī)則翻譯成工程語(yǔ)言教科書上通常會(huì)給三條規(guī)則每個(gè)值有且只有一個(gè)所有者同一時(shí)刻只能有一個(gè)所有者所有者離開作用域時(shí)值被丟棄。這三句話背起來很容易但真正有用的是把它們翻譯成寫代碼時(shí)的判斷依據(jù)。第一條規(guī)則的工程含義是誰(shuí)創(chuàng)建誰(shuí)負(fù)責(zé)收尾。你在函數(shù)里String::from出來的東西如果沒被移交給別人函數(shù)結(jié)束時(shí)它就被釋放。這讓你不需要在每一條提前返回的分支上補(bǔ)釋放語(yǔ)句也不需要在出錯(cuò)路徑上小心翼翼地對(duì)齊資源清理邏輯。第二條規(guī)則管的是并發(fā)和別名安全。只有一個(gè)所有者意味著沒有別人能偷偷把這塊內(nèi)存釋放掉或者改寫掉。這是 Rust 在編譯期就能給出內(nèi)存安全保證的根基——不是靠運(yùn)行時(shí)檢查而是靠根本不存在第二個(gè)能改它的人。第三條規(guī)則定義了釋放時(shí)機(jī)作用域結(jié)束確定析構(gòu)。這一點(diǎn)后面還會(huì)展開因?yàn)樗屠厥兆畋举|(zhì)的區(qū)別就在這里——GC 的回收時(shí)機(jī)是不確定的你可能申請(qǐng)了一塊內(nèi)存程序跑了十分鐘才回收它而 Rust 的釋放時(shí)機(jī)在編譯期就已經(jīng)寫在作用域邊界上了。1.3 為什么不用 GC 也能保證安全很多人會(huì)問既然有所有權(quán)那是不是等于把內(nèi)存管理的活兒從運(yùn)行時(shí)搬到了編譯期這個(gè)理解方向?qū)Φ粔驕?zhǔn)確。更貼切的說法是Rust 把內(nèi)存什么時(shí)候可以安全釋放這個(gè)問題轉(zhuǎn)化成了這段代碼能不能通過類型檢查這個(gè)問題。編譯器不需要知道程序運(yùn)行時(shí)到底走哪條分支它只需要在每一條可能的路徑上都驗(yàn)證沒有任何一個(gè)值的生命周期超過它的所有者沒有任何一個(gè)引用在使用時(shí)指向已經(jīng)失效的內(nèi)存。驗(yàn)證通過就生成代碼驗(yàn)證不過就報(bào)錯(cuò)。運(yùn)行時(shí)沒有任何額外的簿記開銷——不掃描對(duì)象圖不維護(hù)引用計(jì)數(shù)除非你顯式用了Rc不暫停程序。代價(jià)自然也有編譯期要做的推理更重編譯速度慢于同等規(guī)模的 C 代碼更重要的是程序員需要把數(shù)據(jù)的所有權(quán)歸屬想清楚才能寫出能編譯的代碼。這不是語(yǔ)法問題是設(shè)計(jì)問題。我見過不少人卡在這一步本質(zhì)上是習(xí)慣了到處都能拿到引用的寫法一時(shí)轉(zhuǎn)不過彎。2. 棧、堆與 Copy 的邊界所有權(quán)只對(duì)有主之物較真剛上手時(shí)最容易產(chǎn)生的困惑是為什么let a 1; let b a;之后a還能用而String就不行如果所有權(quán)是鐵律為什么整數(shù)有特權(quán)答案藏在數(shù)據(jù)放在哪兒這個(gè)更底層的問題里——所有權(quán)系統(tǒng)并不是對(duì)所有類型一視同仁它對(duì)擁有堆資源的類型格外嚴(yán)格。2.1 棧上數(shù)據(jù)的復(fù)制是廉價(jià)的i32占 4 個(gè)字節(jié)全部在棧上復(fù)制這 4 個(gè)字節(jié)的成本和復(fù)制一個(gè)指針差不多而且復(fù)制完之后兩個(gè)變量各自獨(dú)立誰(shuí)也不會(huì)影響誰(shuí)。對(duì)于這類類型move 和 copy 在機(jī)器碼層面沒有區(qū)別既然沒有區(qū)別就沒有必要禁止原變量繼續(xù)使用。這就是Copytrait 的作用它告訴編譯器這個(gè)類型按位復(fù)制之后新舊兩份都是完整有效的不需要轉(zhuǎn)移所有權(quán)?；緮?shù)值類型、bool、char、以及由Copy類型組成的元組和數(shù)組都實(shí)現(xiàn)了Copy。let a 42; let b a; println!({} {}, a, b); // 都能用因?yàn)?i32: Copy let t1 (1, 2, 3); let t2 t1; println!({:?}, t1); // 元組里全是 Copy 類型所以 t1 仍然有效這里有個(gè)容易忽略的細(xì)節(jié)Copy不是自動(dòng)推導(dǎo)的。如果你自己定義了一個(gè)結(jié)構(gòu)體哪怕它所有字段都是i32默認(rèn)也不實(shí)現(xiàn)Copy需要顯式#[derive(Copy, Clone)]。這個(gè)設(shè)計(jì)很克制——因?yàn)橐坏?shí)現(xiàn)了Copy就意味著這個(gè)類型可以被隱式復(fù)制如果這個(gè)類型將來加了析構(gòu)邏輯比如實(shí)現(xiàn)了Drop就會(huì)產(chǎn)生語(yǔ)義沖突編譯器會(huì)直接禁止。注意實(shí)現(xiàn)了Drop的類型不能同時(shí)實(shí)現(xiàn)Copy。這不是限制是保護(hù)。你不可能既想讓編譯器悄悄復(fù)制一份又想在銷毀時(shí)執(zhí)行自定義邏輯。2.2 Copy 與 Clone 不是同義詞這兩個(gè) trait 經(jīng)常被混為一談但它們的語(yǔ)義差得很遠(yuǎn)。Copy是隱式的、按位的、廉價(jià)的編譯器會(huì)在賦值、傳參、返回時(shí)自動(dòng)插入復(fù)制。Clone是顯式的你必須手寫.clone()而且它可能非常昂貴——VecString的clone會(huì)把里面每一個(gè)String的堆緩沖區(qū)都重新分配一遍。let v1 vec![String::from(a), String::from(b)]; let v2 v1.clone(); // 顯式深拷貝堆上重新分配了三塊內(nèi)存 println!({}, v1.len()); // v1 依然有效我在代碼審查里見過不少.clone()被當(dāng)成消除借用檢查報(bào)錯(cuò)的萬能藥來用。短期確實(shí)能讓代碼編譯過去但如果在熱路徑上對(duì)一個(gè)幾千元素的Vec無腦 clone性能會(huì)掉得很難看。判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果這個(gè) clone 之后原變量就不再使用了那大概率應(yīng)該改成 move如果兩個(gè)變量確實(shí)要各自獨(dú)立演化那 clone 才有正當(dāng)性。2.3 函數(shù)簽名就是所有權(quán)契約函數(shù)參數(shù)是最能體現(xiàn)所有權(quán)設(shè)計(jì)意圖的地方?？聪旅孢@三種寫法它們對(duì)調(diào)用者的約束完全不同fn take_ownership(s: String) { /* s 在函數(shù)結(jié)束時(shí)被釋放 */ } fn borrow(s: str) - usize { s.len() } fn give_back(s: String) - String { s }第一種調(diào)用者傳進(jìn)去之后就不能再用了所有權(quán)徹底移交。第二種只讀借用調(diào)用者傳s或者直接傳字符串字面量都行函數(shù)內(nèi)部改不了內(nèi)容。第三種最啰嗦接收所有權(quán)再還回來實(shí)際上等價(jià)于我要修改它但我懶得寫借用——除非確實(shí)需要消耗掉再重建否則應(yīng)該寫成fn modify(s: mut String)。選哪種不是風(fēng)格問題是接口契約問題。參數(shù)寫成String就意味著調(diào)用方要么放棄這個(gè)值要么自己先 clone 一份。參數(shù)寫成str調(diào)用方傳什么都行——String會(huì)自動(dòng)解引用成str字符串字面量static str也能直接用。這就是為什么庫(kù)函數(shù)里常見impl AsRefstr或者str這樣的簽名接收方越寬容調(diào)用方越省事。3. 借用檢查器怎么推理從詞法作用域到 NLL所有權(quán)解決了誰(shuí)負(fù)責(zé)釋放但光有所有權(quán)寫不了實(shí)際代碼——你總得讓別人臨時(shí)看一眼數(shù)據(jù)。借用borrowing就是為此存在的而借用檢查器則是整個(gè)體系里最容易被誤解的部分。很多人以為它是作用域級(jí)別的檢查這個(gè)印象在 Rust 2015 時(shí)代勉強(qiáng)成立從 2018 edition 引入 NLL 之后就已經(jīng)不準(zhǔn)確了。3.1 借用規(guī)則的本質(zhì)是讀寫沖突檢測(cè)兩條借用規(guī)則同一時(shí)刻要么有任意多個(gè)不可變借用要么有唯一一個(gè)可變借用。翻譯成大白話就是要么大家一起看要么一個(gè)人改不能邊看邊改。為什么這條規(guī)則能防住內(nèi)存錯(cuò)誤想想 C 里那個(gè)經(jīng)典陷阱拿到vector的迭代器然后往里面push_back容器擴(kuò)容導(dǎo)致底層緩沖區(qū)重新分配原來那個(gè)迭代器指向的內(nèi)存已經(jīng)被釋放后續(xù)解引用就是未定義行為。這類 bug 在 C 里極其隱蔽因?yàn)樗辉谌萘縿偤貌粔?、觸發(fā)擴(kuò)容時(shí)才出現(xiàn)測(cè)試環(huán)境數(shù)據(jù)量小的時(shí)候根本復(fù)現(xiàn)不了。Rust 在編譯期就把這種可能性排除了let mut v vec![1, 2, 3]; let first v[0]; // 不可變借用 v.push(4); // 需要可變借用沖突 println!({}, first);編譯器會(huì)告訴你不可變借用還活著的時(shí)候不能對(duì)v做可變借用。如果你把println!刪掉讓first在push之前就不再使用那么這段代碼反而能編譯通過——這正是 NLL 帶來的變化。3.2 NLL 改變了什么NLL 全稱是 Non-Lexical Lifetimes核心變化是借用的生命周期在它最后一次被使用的地方結(jié)束而不是在它所在的作用域結(jié)束時(shí)結(jié)束。這個(gè)變化看起來只是編譯器變聰明了實(shí)際對(duì)寫代碼的體驗(yàn)影響巨大。let mut data vec![1, 2, 3]; let r data[0]; println!({}, r); // r 最后一次使用 data.push(4); // 在舊規(guī)則下這里會(huì)報(bào)錯(cuò)NLL 下完全合法在舊規(guī)則里r的借用一直持續(xù)到整個(gè)函數(shù)塊結(jié)束push必然沖突。NLL 下編譯器看的是數(shù)據(jù)流r在println!之后就再也沒被用過借用提前結(jié)束后面的可變操作自然就沒問題了。這個(gè)特性對(duì)初學(xué)者的意義在于很多以前必須靠額外花括號(hào)或者克隆才能繞過去的寫法現(xiàn)在直接寫就行。不過也別指望編譯器無所不能——一旦借用跨越了控制流分支、或者被存進(jìn)了結(jié)構(gòu)體、或者被閉包捕獲分析難度就會(huì)上升報(bào)錯(cuò)依然會(huì)出現(xiàn)。遇到這種情況先想清楚這個(gè)引用最長(zhǎng)要活到哪一行問題通常就清楚了。3.3 三個(gè)高頻報(bào)錯(cuò)的拆解路徑我整理了一下自己踩過和幫別人看過最多的三類借用報(bào)錯(cuò)它們的排查思路并不相同。第一類是cannot borrow as mutable because it is also borrowed as immutable。上文那個(gè)vec的例子就是典型。處理方法是把讀操作和寫操作在時(shí)間上錯(cuò)開——先取值再改容器。如果是循環(huán)里同時(shí)讀寫考慮收集一份索引或者用split_at_mut拆分借用。第二類是returns a value referencing data owned by the current function。這個(gè)報(bào)錯(cuò)的意思是函數(shù)試圖返回一個(gè)指向函數(shù)內(nèi)部局部變量的引用函數(shù)一返回那個(gè)局部變量就被銷毀了返回的引用立刻變成懸垂引用。解法有兩條要么返回所有權(quán)String而不是str要么這個(gè)引用的來源必須是參數(shù)傳進(jìn)來的——參數(shù)的生命周期比函數(shù)體長(zhǎng)。第三類是cannot move out of ... which is behind a shared reference。想從Struct里把一個(gè)字段移出來不允許。因?yàn)橐谱咧笤Y(jié)構(gòu)體就殘缺了而別人還持有它的引用。解法是用clone復(fù)制一份或者用std::mem::take/Option::take把字段替換成默認(rèn)值。提示讀報(bào)錯(cuò)信息時(shí)重點(diǎn)看編譯器給出的help部分它經(jīng)常直接告訴你consider borrowing here或者consider cloning。但要注意編譯器給的建議是能編譯的建議不一定是最優(yōu)解。.clone()能讓報(bào)錯(cuò)消失但性能賬還得自己算。4. 與傳統(tǒng)內(nèi)存管理的正面比較聊所有權(quán)系統(tǒng)的價(jià)值放到對(duì)比里最清楚。常見的三種內(nèi)存管理路線手動(dòng)管理、追蹤式垃圾回收、所有權(quán)加 RAII。它們各自的取舍差別很大沒有哪一種在所有場(chǎng)景下都占優(yōu)但如果只做單方面宣傳就容易失真。管理方式釋放時(shí)機(jī)運(yùn)行時(shí)開銷典型風(fēng)險(xiǎn)手動(dòng) malloc/free由程序員顯式調(diào)用幾乎為零懸垂指針、重復(fù)釋放、內(nèi)存泄漏、忘記對(duì)齊追蹤式 GC對(duì)象不可達(dá)后由回收器決定掃描開銷、可能的暫停內(nèi)存放大、停頓抖動(dòng)、回收時(shí)機(jī)不可控所有權(quán) RAII所有者離開作用域編譯期確定無額外運(yùn)行時(shí)簿記學(xué)習(xí)曲線、循環(huán)引用需手動(dòng)打破、編譯期負(fù)擔(dān)4.1 手動(dòng)管理與追蹤式回收的代價(jià)手動(dòng)管理的優(yōu)點(diǎn)是極致可控。什么時(shí)候釋放、在哪里釋放、要不要池化全由你決定沒有黑箱。缺點(diǎn)是把正確性完全押在人的注意力上——一段有三四十個(gè)提前返回分支的函數(shù)只要有一條分支忘了釋放就是內(nèi)存泄漏如果兩條分支釋放了同一塊內(nèi)存就是未定義行為而且這種 bug 往往在壓力測(cè)試下才暴露。追蹤式回收把正確性從人手里接管過來代價(jià)是運(yùn)行時(shí)的不確定性?；厥掌餍枰谀硞€(gè)時(shí)刻掃描存活對(duì)象這個(gè)過程可能造成暫停即使做了增量回收和并發(fā)標(biāo)記內(nèi)存占用的峰值通常還是高于手動(dòng)管理因?yàn)閷?duì)象在被證明不可達(dá)之前都不能被回收。對(duì)于延遲敏感的場(chǎng)景回收帶來的抖動(dòng)是需要認(rèn)真評(píng)估的因素。Rust 走的第三條路如果編譯器能在編譯期證明這塊內(nèi)存在某個(gè)點(diǎn)之后不可能再被使用那就直接在那個(gè)點(diǎn)插入釋放指令。作用域結(jié)束就是這樣一個(gè)點(diǎn)因?yàn)樗袡?quán)規(guī)則保證了沒有任何引用能活過作用域邊界。這樣既沒有回收器的運(yùn)行時(shí)開銷也不需要程序員手動(dòng)寫釋放語(yǔ)句。4.2 Drop 的確定性與析構(gòu)順序Droptrait 是這個(gè)模型落地的關(guān)鍵。實(shí)現(xiàn)Drop的類型在所有者離開作用域時(shí)自動(dòng)調(diào)用drop方法。這個(gè)調(diào)用的時(shí)機(jī)是確定的、可預(yù)測(cè)的和 GC 那種遲早會(huì)回收完全不同。struct Guard(static str); impl Drop for Guard { fn drop(mut self) { println!(releasing {}, self.0); } } fn main() { let _a Guard(a); let _b Guard(b); // 輸出順序releasing b、releasing a }局部變量的析構(gòu)順序是聲明的逆序也就是后進(jìn)先出。這個(gè)規(guī)則和棧的自然結(jié)構(gòu)一致也很符合直覺后創(chuàng)建的對(duì)象可能依賴先創(chuàng)建的對(duì)象所以要先銷毀。而結(jié)構(gòu)體內(nèi)部的字段析構(gòu)順序是聲明順序從前往后——這一點(diǎn)和局部變量相反我第一次遇到時(shí)也愣了一下后來想通了字段按聲明順序析構(gòu)可以保證先聲明的字段先失效后聲明的字段如果持有對(duì)前面字段的引用雖然安全 Rust 里很難構(gòu)造也不會(huì)出現(xiàn)引用懸垂。這個(gè)確定性在資源管理上價(jià)值巨大。文件句柄、網(wǎng)絡(luò)連接、鎖守衛(wèi)、臨時(shí)目錄這些資源都可以包在實(shí)現(xiàn)了Drop的類型里靠作用域自動(dòng)釋放。哪怕函數(shù)中途panic棧展開過程依然會(huì)調(diào)用析構(gòu)函數(shù)除非編譯選項(xiàng)關(guān)閉了展開。這套 RAII 模式在 C 里已經(jīng)驗(yàn)證了幾十年Rust 把它和所有權(quán)綁定得更緊——因?yàn)樗袡?quán)唯一所以析構(gòu)只會(huì)執(zhí)行一次天然不會(huì)重復(fù)釋放。4.3 循環(huán)引用所有權(quán)模型的盲區(qū)所有權(quán)不是銀彈它有一個(gè)明確的盲區(qū)環(huán)形結(jié)構(gòu)。如果 A 持有 BB 又持有 A那么兩者的引用計(jì)數(shù)永遠(yuǎn)不歸零誰(shuí)也沒法釋放誰(shuí)。在單所有權(quán)模型下這個(gè)問題更直接——你根本無法同時(shí)讓兩個(gè)對(duì)象互相擁有對(duì)方因?yàn)樗袡?quán)唯一。標(biāo)準(zhǔn)庫(kù)給出的方案是Rc加Weak。RcT是引用計(jì)數(shù)指針允許多個(gè)所有者共享同一份數(shù)據(jù)WeakT是弱引用它指向數(shù)據(jù)但不增加計(jì)數(shù)訪問時(shí)需要先upgrade檢查數(shù)據(jù)是否還活著。打破循環(huán)的做法就是強(qiáng)引用指一個(gè)方向弱引用指反方向。use std::rc::{Rc, Weak}; use std::cell::RefCell; struct Node { next: OptionRcRefCellNode, prev: OptionWeakRefCellNode, // 反向用 Weak不增加計(jì)數(shù) }需要強(qiáng)調(diào)的是Rc已經(jīng)偏離了零成本的范疇——每次克隆和丟棄都要修改計(jì)數(shù)而且計(jì)數(shù)器本身是普通的整數(shù)多線程環(huán)境下不安全所以多線程場(chǎng)景得換Arc代價(jià)是原子操作。我個(gè)人的經(jīng)驗(yàn)是能用樹形結(jié)構(gòu)表達(dá)的關(guān)系盡量別做成圖一旦引入RcRefCellT代碼的可讀性和性能都會(huì)下降而且運(yùn)行時(shí)的借用檢查RefCell在運(yùn)行期檢查借用規(guī)則違規(guī)直接 panic把編譯期保障也削弱了一部分。5. 把所有權(quán)用出性能幾個(gè)能落地的寫法理解了規(guī)則接下來是實(shí)操層面。所有權(quán)系統(tǒng)不只是安全保證它同時(shí)也是一份性能設(shè)計(jì)指南——很多寫法之所以能過編譯恰恰說明它在內(nèi)存上是高效的。5.1 傳參用引用還是 move判斷標(biāo)準(zhǔn)我總結(jié)成一句話看這個(gè)值在調(diào)用之后還有沒有用。如果沒用直接 move零成本如果還要用就借用避免復(fù)制。fn process(data: Vecu8) - usize { data.len() } let buf vec![0u8; 1024]; let n process(buf); // buf 被 move 走了之后的代碼不能再用它這個(gè)寫法乍看別扭但在管道式的代碼里非常自然數(shù)據(jù)從上游流向下游每一站都消費(fèi)掉上一站的產(chǎn)物全程沒有一次多余的復(fù)制。如果確實(shí)要保留傳[u8]就行fn process(data: [u8]) - usize { data.len() } let n process(buf); println!({}, buf.len()); // 還能用這里有個(gè)細(xì)節(jié)值得說Vecu8和[u8]在函數(shù)參數(shù)位置上后者更通用。因?yàn)閂ecT可以自動(dòng)解引用成[T]但反過來不行數(shù)組和切片就沒法傳。寫庫(kù)的時(shí)候養(yǎng)成參數(shù)盡量用切片、用str的習(xí)慣調(diào)用方的體驗(yàn)會(huì)好很多。5.2 讓編譯器替你決定Cow 與 AsRef有些場(chǎng)景你不確定到底需不需要復(fù)制——輸入可能本來就是想要的格式只需要原樣返回也可能是別的格式得轉(zhuǎn)換一下。這時(shí)候CowClone on Write就派上用場(chǎng)了。use std::borrow::Cow; fn normalize(input: str) - Cowstr { if input.contains( ) { Cow::Owned(input.replace( , _)) // 需要改分配新內(nèi)存 } else { Cow::Borrowed(input) // 不用改零成本 } }返回類型Cowstr表示可能借用也可能擁有。調(diào)用方可以把它當(dāng)str用實(shí)現(xiàn)了Deref只有確實(shí)需要所有權(quán)時(shí)才調(diào)用into_owned()。這個(gè)模式在解析、文本處理、配置讀取里非常實(shí)用——大部分情況下輸入是干凈的走借用分支一次堆分配都不需要。AsRef則是另一個(gè)方向的寬容。函數(shù)簽名寫成fn openP: AsRefPath(path: P)調(diào)用方傳str、String、PathBuf、Path都行不需要手動(dòng)轉(zhuǎn)換。這類泛型簽名會(huì)讓編譯產(chǎn)物略微膨脹單態(tài)化但換來的調(diào)用便利性通常值得。5.3 結(jié)構(gòu)體設(shè)計(jì)的取舍最后聊聊結(jié)構(gòu)體。新手常犯的一個(gè)錯(cuò)是不管三七二十一字段全用引用然后被生命周期標(biāo)注折磨得死去活來。// 不推薦一開始就上生命周期 struct Configa { name: a str, path: a str, }這個(gè)結(jié)構(gòu)體只要被存儲(chǔ)、被返回、被放進(jìn)集合生命周期標(biāo)注就會(huì)像藤蔓一樣蔓延到所有用到它的地方。我的建議是先讓結(jié)構(gòu)體擁有數(shù)據(jù)用String、Vec等性能分析真的指出這里是瓶頸再考慮改成借用。一個(gè)Config結(jié)構(gòu)體多幾次分配對(duì)大多數(shù)程序來說完全可以接受而開發(fā)效率的損失是實(shí)打?qū)嵉?。另一種情況是字段很多但大部分時(shí)候只讀。這時(shí)候可以用ArcInner把一堆字段包起來克隆結(jié)構(gòu)體時(shí)只增加一次引用計(jì)數(shù)而不是深拷貝所有字段。這在配置共享、上下文傳遞的場(chǎng)景里非常常見代價(jià)是訪問字段時(shí)多一層間接尋址以及Arc的原子操作開銷。還有個(gè)小技巧值得提BoxT的大小固定是一個(gè)指針8 字節(jié)把大結(jié)構(gòu)體裝箱之后移動(dòng)它的成本從復(fù)制整個(gè)結(jié)構(gòu)體降到復(fù)制一個(gè)指針。如果一個(gè)結(jié)構(gòu)體有幾百字節(jié)又要在Vec里頻繁移動(dòng)裝箱能顯著減少memcpy的量。這也是所有權(quán)模型的一個(gè)副產(chǎn)品——因?yàn)?move 的語(yǔ)義是轉(zhuǎn)移而非復(fù)制編譯器在某些情況下可以直接在原地構(gòu)造避免中間臨時(shí)對(duì)象的產(chǎn)生。6. 幾個(gè)我真正踩過的坑和對(duì)應(yīng)的改法理論講完說點(diǎn)實(shí)戰(zhàn)里反復(fù)出現(xiàn)的問題。這些坑在文檔里往往一句話帶過但真遇上時(shí)能卡你半天。第一個(gè)坑是閉包捕獲。閉包默認(rèn)按需捕獲——只讀就按引用捕獲要改就按可變引用捕獲要 move 就按值捕獲。如果你把一個(gè)閉包傳給新線程編譯器會(huì)要求move于是整個(gè)環(huán)境都被搬進(jìn)閉包外面的變量立刻失效。let data vec![1, 2, 3]; let handle std::thread::spawn(move || { println!({:?}, data); }); handle.join().unwrap(); // println!({:?}, data); // 報(bào)錯(cuò)data 已經(jīng)被 move 進(jìn)閉包如果確實(shí)需要主線程和子線程共享數(shù)據(jù)別用move硬搬改用Arc包一層再克隆進(jìn)閉包。克隆Arc只增加計(jì)數(shù)兩個(gè)線程都能訪問同一份數(shù)據(jù)。第二個(gè)坑是迭代器里的借用沖突。想在遍歷的同時(shí)修改容器這條在安全 Rust 里就是走不通的。正確做法是先把要改的索引收集起來遍歷結(jié)束后統(tǒng)一處理或者用retain、drain這類專門為邊遍歷邊修改設(shè)計(jì)的 API。let mut v vec![1, 2, 3, 4]; v.retain(|x| x % 2 0); // 內(nèi)部已經(jīng)處理好借用關(guān)系第三個(gè)坑是返回引用的函數(shù)。寫fn get_name(self) - str是沒問題的因?yàn)榉祷氐囊媒壎ㄔ趕elf的生命周期上。但如果函數(shù)里創(chuàng)建了一個(gè)新的String想返回它的切片編譯器一定攔你——那個(gè)String在函數(shù)返回時(shí)就沒了。這時(shí)候只能返回String把所有權(quán)交給調(diào)用方。注意static str只適用于編譯期就確定的字面量或者Box::leak出來永不釋放的內(nèi)存。別為了讓報(bào)錯(cuò)消失隨手加static那是把內(nèi)存泄漏寫進(jìn)類型簽名里。第四個(gè)坑和RefCell有關(guān)。它在運(yùn)行時(shí)執(zhí)行借用檢查違規(guī)不是編譯錯(cuò)誤而是panic。我遇到過一次在同一個(gè)作用域里先borrow_mut()拿到可變借用然后調(diào)用的函數(shù)內(nèi)部又嘗試borrow()程序直接崩了報(bào)錯(cuò)信息指向的是RefCell內(nèi)部跟業(yè)務(wù)邏輯毫無關(guān)系排查花了不少時(shí)間。后來養(yǎng)成的習(xí)慣是RefCell的借用盡量短拿到值就盡快drop掉守衛(wèi)別讓它在整個(gè)函數(shù)體里掛著。最后一個(gè)經(jīng)驗(yàn)是關(guān)于閱讀編譯器報(bào)錯(cuò)的心態(tài)。Rust 的報(bào)錯(cuò)信息質(zhì)量在所有語(yǔ)言里都算靠前的它會(huì)畫出借用開始和沖突的兩處位置會(huì)給出修改建議。我現(xiàn)在的習(xí)慣是先不看具體代碼只看它指出的兩個(gè)位置問自己這兩行之間這個(gè)數(shù)據(jù)的讀寫關(guān)系到底是什么。想清楚了改法自然就有了。反過來如果只是照著建議加clone加mut同類問題會(huì)在別的地方反復(fù)出現(xiàn)。7. 什么時(shí)候該繞開所有權(quán)邊界情況的判斷最后聊一個(gè)容易被忽略的話題所有權(quán)系統(tǒng)不是萬能的有些場(chǎng)景下硬套反而更糟。最典型的是圖形界面和場(chǎng)景圖這類天然存在環(huán)形引用的結(jié)構(gòu)父子節(jié)點(diǎn)互相引用是常態(tài)。這類代碼如果用純安全 Rust 寫會(huì)被RcRefCell和各種運(yùn)行時(shí)借用檢查攪得很亂。這時(shí)候可以考慮用索引代替引用——所有節(jié)點(diǎn)存在一個(gè)Vec里節(jié)點(diǎn)之間用usize下標(biāo)互相指向。這樣做繞開了借用檢查器但代價(jià)是失去了一部分編譯期保障下標(biāo)的有效性得自己保證。業(yè)界不少成熟的做法就是這么干的收益是可讀性和性能都回來了。另一類是性能極度敏感的底層代碼比如自己實(shí)現(xiàn)的內(nèi)存分配器、無鎖數(shù)據(jù)結(jié)構(gòu)。這類代碼里需要大量的裸指針操作和unsafe所有權(quán)檢查在這里幫不上什么忙反而會(huì)礙事。合理的做法是把unsafe收斂在一個(gè)小模塊里對(duì)外仍然暴露安全接口用文檔和測(cè)試來保證內(nèi)部的不變量。還有一種情況是生命周期標(biāo)注復(fù)雜到影響可維護(hù)性。我見過一個(gè)結(jié)構(gòu)體帶四個(gè)生命周期參數(shù)每次新增方法都要重新推導(dǎo)一遍。這種時(shí)候把數(shù)據(jù)改成擁有的形式或者用Arc共享往往是更務(wù)實(shí)的選擇。編譯期檢查的價(jià)值在于減少 bug如果為了通過檢查而把代碼寫得沒人看得懂那就本末倒置了。我個(gè)人在實(shí)際項(xiàng)目里的體會(huì)是所有權(quán)系統(tǒng)最大的價(jià)值不在于讓你寫出絕對(duì)安全的代碼而在于它強(qiáng)迫你在寫代碼的時(shí)候就想清楚數(shù)據(jù)的歸屬和生命周期。這個(gè)思考過程本身就會(huì)篩掉大量設(shè)計(jì)上的含糊之處。被編譯器攔住的那幾十次換來的往往是對(duì)模塊邊界更清晰的認(rèn)識(shí)——這個(gè)收益比少寫幾行釋放語(yǔ)句要大得多。