寫 Rust 這幾年被問得最多的一句話就是“所有權(quán)到底是個啥”。我一直覺得這個中文譯名有點誤導聽起來像某種法律概念實際上它描述的是一件特別樸素的事一塊內(nèi)存由誰負責釋放、什么時候釋放、釋放之前誰有資格讀寫。C 里這件事靠人腦記賬Java、Go 里這件事交給運行時在后臺掃Rust 選了第三條路——把賬本寫進類型系統(tǒng)讓編譯器在編譯期替你記。代價是你得學會跟編譯器講道理收益是運行時沒有停頓、沒有懸垂指針、沒有雙重釋放單線程代碼里的迭代器失效問題基本絕跡。這篇筆記把所有權(quán)、借用檢查、生命周期標注、智能指針這幾塊串起來講重點放在“它怎么影響內(nèi)存管理”這個角度而不是復述語法手冊。適合已經(jīng)能寫點 Rust 但總被借用檢查器攔下來的人也適合從 C 或 Go 轉(zhuǎn)過來、想搞清楚心智模型差異的人。下面所有報錯和改法都是我實際踩過的代碼可以直接抄去跑。1. 三種內(nèi)存管理路線Rust 為什么挑了最難的這條1.1 手動管理與垃圾回收各自的賬單先把三條路擺在桌面上對比不然后面很多設計取舍會顯得莫名其妙。手動管理C、C 的裸指針路線把釋放時機完全交給開發(fā)者性能上限最高內(nèi)存布局最可控代價是任何一次疏忽都會變成線上事故而且這類事故往往在壓力大的時候才暴露。垃圾回收Java、Go、C# 的默認路線把釋放交給運行時開發(fā)者寫得舒服代價是內(nèi)存占用曲線偏高延遲不可預測遇到大堆的時候一次回收能帶來幾十毫秒的抖動。Rust 的所有權(quán)系統(tǒng)是第三條路編譯器在編譯期為每個值推導出唯一的負責方負責方離開作用域就自動釋放檢查全部發(fā)生在編譯期運行時不需要任何額外指令。路線釋放時機運行時開銷典型風險延遲可預測性手動管理開發(fā)者調(diào)用 free/delete接近零懸垂指針、雙重釋放、泄漏高垃圾回收運行時掃描判定5% 到 30% 不等看堆大小停頓抖動、內(nèi)存峰值高低所有權(quán)系統(tǒng)作用域結(jié)束自動 drop編譯期檢查運行時為零學習曲線、改寫數(shù)據(jù)結(jié)構(gòu)高這張表里最關鍵的一列是“運行時開銷”。Rust 的所有權(quán)檢查在編譯完成后就消失了生成的機器碼里沒有任何一條指令是用來“檢查所有權(quán)”的這叫零成本抽象。你付出的是編譯期的思考成本和偶爾的改寫成本換來的是運行時的確定性。1.2 所有權(quán)本質(zhì)上是一套編譯期推導出來的引用計數(shù)我習慣用引用計數(shù)來類比所有權(quán)這個類比能解釋掉八成的疑惑。真正的引用計數(shù)比如RcT是在運行時維護一個整數(shù)每次克隆加一每次銷毀減一減到零就釋放。所有權(quán)系統(tǒng)做的事情幾乎一樣區(qū)別在于編譯器在編譯期就能推導出每個值的引用計數(shù)永遠是 0 或 1既然結(jié)果只有兩種那就不需要在運行時存這個整數(shù)了直接把它編碼進類型檢查規(guī)則里。所以String被賦值給另一個變量之后原變量立刻失效——因為在編譯器的賬本上這個值的所有者已經(jīng)換人了舊主人再訪問就是越權(quán)。這個類比還能解釋另一個現(xiàn)象為什么RcT在 Rust 里被歸到“智能指針”而不是“所有權(quán)”里。因為一旦你真的需要多個所有者編譯期就沒法推導出唯一負責方了只能退回到運行時記賬這就是Rc和Arc存在的原因。理解了這個層次關系你就不會覺得RcRefCellT是一堆奇怪符號的堆砌而會明白它是“編譯期賬本不夠用時的降級方案”。1.3 編譯期到底擋住了哪幾類事故具體一點所有權(quán)加借用檢查主要攔四類問題。第一類是釋放后使用C 里指針指著的內(nèi)存已經(jīng)被free掉讀出來是臟數(shù)據(jù)Rust 里編譯器直接告訴你這個值已經(jīng) move 走了。第二類是雙重釋放兩個指針指向同一塊堆內(nèi)存析構(gòu)函數(shù)跑兩遍堆管理器直接崩Rust 里因為只有一個所有者drop只會執(zhí)行一次。第三類是迭代器失效這是 C 里最陰的一類 bug往vector里push_back之后原來的迭代器可能指向已釋放的舊緩沖區(qū)Rust 里你在遍歷v的同時調(diào)v.push()會直接編譯失敗。第四類是數(shù)據(jù)競爭多個線程同時讀寫同一塊內(nèi)存且沒有同步Rust 靠Send和Sync兩個標記 trait 在編譯期就把不安全的共享擋掉。我印象最深的是第三類。早年寫 C 的時候在一個循環(huán)里刪元素導致迭代器失效程序在小數(shù)據(jù)量下跑得好好的上線之后數(shù)據(jù)量上來才開始隨機崩潰查了兩天才定位到。換成 Rust 之后這種寫法連編譯都過不去等于把調(diào)試成本從線上挪到了敲代碼的那幾分鐘。2. 三條鐵律落地move、Copy、Clone 在內(nèi)存里到底做了什么2.1 三條規(guī)則逐條對照內(nèi)存行為所有權(quán)的規(guī)則只有三條但每一條都對應著實實在在的內(nèi)存動作。第一條每個值有且只有一個所有者。第二條同一時刻只能有一個所有者。第三條所有者離開作用域值被丟棄。這三條合起來的效果是任何一塊堆內(nèi)存的釋放點都是唯一且確定的編譯器在生成代碼的時候就知道該在哪里插入釋放調(diào)用不需要運行時判斷。拿String舉例。let s1 String::from(hello);這一行會在棧上放一個三元組指針、容量、長度在堆上放五個字節(jié)的數(shù)據(jù)。接著let s2 s1;這一行做的事情是把棧上那 24 個字節(jié)復制一份給s2堆上的數(shù)據(jù)一個字節(jié)都不動然后編譯器在符號表里把s1標記為失效。如果你這時候?qū)憄rintln!({}, s1)編譯器報 E0382意思是使用了已經(jīng) move 走的值。注意這里沒有發(fā)生任何堆內(nèi)存分配或復制move 對String這類類型來說是常數(shù)時間操作。2.2 move 不是“搬家”是所有權(quán)憑證的轉(zhuǎn)移很多人以為 move 會把堆上的數(shù)據(jù)搬到新地址這是個誤解。move 搬的只是棧上那個描述符堆數(shù)據(jù)原地不動。這也解釋了為什么對大對象做 move 是廉價的VecT裝一百萬個元素move 一次也只復制 24 個字節(jié)的頭部。真正昂貴的是clone那才是老老實實把堆數(shù)據(jù)復制一份。我用一段代碼把這個差別量化一下你可以直接跑fn main() { let v1: Vecu64 (0..1_000_000).collect(); let start std::time::Instant::now(); let v2 v1; // move只復制頭部 println!(move 耗時: {:?}, start.elapsed()); let start std::time::Instant::now(); let v3 v2.clone(); // clone復制全部堆數(shù)據(jù) println!(clone 耗時: {:?}, start.elapsed()); println!({} {}, v3.len(), std::mem::size_of::Vecu64()); }實測下來 move 通常是納秒級clone 一百萬個u64大概在幾百微秒到一毫秒之間取決于內(nèi)存帶寬。這個差距在高頻路徑上是致命的所以我養(yǎng)成一個習慣函數(shù)簽名里能傳引用就傳引用確實需要轉(zhuǎn)移所有權(quán)才用 move絕不為了圖省事到處寫.clone()。2.3 Copy 與 Clone 的邊界怎么劃Copy和Clone經(jīng)常被混為一談其實差別很大。Copy是一個標記 trait表示這個類型的值可以按位復制賦值之后原變量依然可用。能實現(xiàn)Copy的類型有兩個硬性條件所有字段都是Copy并且這個類型本身沒有實現(xiàn)Drop。整數(shù)、浮點數(shù)、布爾、字符、裸指針、以及由它們組成的固定大小數(shù)組和元組都是Copy的。String、VecT、BoxT都不是因為它們管理著堆內(nèi)存按位復制會導致兩個所有者指向同一塊堆這正是所有權(quán)系統(tǒng)要避免的。Clone則是一個普通 trait需要你顯式調(diào)用.clone()它允許你自定義復制邏輯比如深拷貝堆數(shù)據(jù)。任何類型都可以實現(xiàn)Clone包括實現(xiàn)了Drop的類型。這里有個常見的性能坑給一個大結(jié)構(gòu)體derive(Clone)之后在循環(huán)里順手寫.clone()傳參編譯器不會提醒你代碼跑起來才發(fā)現(xiàn)慢得離譜。我的做法是只有在確實需要獨立副本的地方才 deriveClone而且在大結(jié)構(gòu)體上會刻意不 derive逼著自己去想清楚到底該傳引用還是轉(zhuǎn)移所有權(quán)。順便說一個實測有用的小技巧用std::mem::size_of快速看一眼類型的棧上開銷很多“為什么這個結(jié)構(gòu)體這么大”的疑惑一測就清楚了fn main() { println!(String {}, std::mem::size_of::String()); // 24 println!(str {}, std::mem::size_of::str()); // 16 println!(Boxu64 {}, std::mem::size_of::Boxu64()); // 8 println!(OptionBoxu64 {}, std::mem::size_of::OptionBoxu64()); // 8 println!(Rcu64 {}, std::mem::size_of::Rcu64()); // 8 }OptionBoxT只占 8 字節(jié)這件事值得單獨說一下。編譯器發(fā)現(xiàn)Box的指針不可能是零于是用空指針這個非法值來表示None這叫空指針優(yōu)化。這個優(yōu)化在鏈表、樹這類遞歸結(jié)構(gòu)里非常關鍵不然每個節(jié)點都要多帶一個字節(jié)的判別位再加對齊填充內(nèi)存占用會明顯上升。2.4 函數(shù)簽名就是一份所有權(quán)契約我一直建議新手把函數(shù)簽名當成一份合同來讀。參數(shù)寫T表示調(diào)用方把這個值的所有權(quán)交出去了函數(shù)返回之后調(diào)用方不能再碰它寫T表示只借來讀函數(shù)內(nèi)部改不了寫mut T表示借來改借用期間調(diào)用方不能用寫self和mut self是同樣的道理只是作用在方法接收者上。一份好的簽名應該讓調(diào)用方一眼看出“我還能不能用這個變量”。fn consume(s: String) - usize { s.len() } // 拿走所有權(quán) fn inspect(s: str) - usize { s.len() } // 只借用讀 fn append(s: mut String, tail: str) { s.push_str(tail); } // 借用改 fn create() - String { String::from(new) } // 交出所有權(quán)這四行基本覆蓋了九成場景。我踩過的一個坑是函數(shù)參數(shù)寫成String但其實只讀一下長度結(jié)果調(diào)用方每次都得 clone 一份才能傳進去。改成str之后String和字符串字面量都能直接傳調(diào)用方省掉了所有 clone。這個改動看起來小在一個熱路徑上能省掉可觀的分配次數(shù)。3. 借用檢查器到底在檢查什么3.1 共享不可變、獨占可變借用規(guī)則只有一句話任意時刻你要么擁有多個不可變引用要么擁有一個可變引用兩者不能同時存在。另外所有引用必須始終有效。這條規(guī)則的動機有兩個層次。淺層是為了防止數(shù)據(jù)競爭多個線程同時讀是安全的只要有寫就必須獨占。深層是為了防止同一份數(shù)據(jù)在讀取過程中被別處改掉導致讀到的內(nèi)容前后不一致。舉一個最典型的例子遍歷的同時修改集合fn main() { let mut v vec![1, 2, 3]; for x in v { if *x 2 { v.push(4); // 報錯 E0502 } } }編譯器會告訴你v已經(jīng)被不可變借用不能再作為可變借用。這個限制在 C 里是允許的代價是push可能觸發(fā)重新分配原來的迭代器變成懸垂指針接著就是未定義行為。Rust 直接把這條路堵死。正確的寫法是先收集要改的內(nèi)容循環(huán)結(jié)束后再統(tǒng)一改fn main() { let mut v vec![1, 2, 3]; let need_push v.iter().any(|x| x 2); if need_push { v.push(4); } }這種“先讀后寫”的拆分模式我用了無數(shù)次幾乎所有的借用沖突都能用這個思路化解。它看起來多寫了一行實際上是把原本隱藏的時序依賴顯式化了代碼反而更清楚。3.2 NLL 讓借用的結(jié)束點變聰明了早期的 Rust 用詞法作用域判斷借用何時結(jié)束只要變量還在作用域里借用就算沒結(jié)束于是很多寫法通不過。從 2018 edition 開始默認啟用非詞法生命周期NLL借用的有效期縮短到“最后一次使用”為止。這個改進影響巨大很多以前必須用花括號強行劃作用域的代碼現(xiàn)在可以直接寫。fn main() { let mut data vec![1, 2, 3]; let first data[0]; println!({}, first); // first 的最后一次使用 data.push(4); // 現(xiàn)在合法了借用已經(jīng)結(jié)束 println!({:?}, data); }這段代碼在老版本會報錯因為data的可變借用和first的不可變借用被認為在同一個作用域里共存。NLL 之后編譯器看出first在println之后就沒用了借用提前結(jié)束后面的push就不沖突了。理解這一點很重要它意味著你不需要為了繞開借用檢查而寫一堆莫名其妙的花括號只要讓借用自然地在最后一次使用處結(jié)束就行。3.3 生命周期標注不延長壽命只是描述關系生命周期這個詞嚇退過不少人其實它的作用被嚴重夸大了。生命周期標注不會讓任何值的存活時間變長或變短它只是告訴編譯器“這幾個引用之間的存活關系是這樣的”方便編譯器做檢查。真正決定值活多久的永遠是它所在的作用域。最經(jīng)典的例子是返回兩個字符串切片里較長的那個fn longesta(x: a str, y: a str) - a str { if x.len() y.len() { x } else { y } }不寫標注的話編譯器報 E0106因為它無法確定返回的引用到底跟著x還是y活。a的意思是返回值的存活時間不會超過x和y中較短的那個。這是一個上界約束不是延長。調(diào)用方拿到返回值之后只要保證在x和y都還活著的時候用它就行。生命周期省略規(guī)則有三條記住這三條能省掉大部分手寫標注。第一每個引用參數(shù)各自獲得一個獨立的生命周期參數(shù)。第二如果只有一個輸入引用參數(shù)那么輸出的生命周期全部等于它。第三如果有self或mut self那么輸出的生命周期全部等于self的。第三條是方法簽名的常用規(guī)則所以大多數(shù)方法不需要手寫生命周期標注。3.4 結(jié)構(gòu)體持有引用必須寫生命周期這是新手最容易卡住的地方。結(jié)構(gòu)體里如果放了引用就必須給結(jié)構(gòu)體加生命周期參數(shù)因為編譯器需要確保這個引用比結(jié)構(gòu)體本身活得久。否則結(jié)構(gòu)體還存在的時候它指向的數(shù)據(jù)可能已經(jīng)被釋放了。struct Tokena { text: a str, line: usize, } impla Tokena { fn len(self) - usize { self.text.len() } }Tokena讀作“這個 Token 的有效期不能超過a”。這意味著任何持有Token的地方那個被引用的字符串也得活著編譯器會一路向上檢查。這個傳播有時候會很煩一個底層結(jié)構(gòu)加了生命周期上面三層都得跟著加。我的處理策略是分場景的。如果這段數(shù)據(jù)是短命的、臨時的、解析完就用完的那就老老實實加生命周期零拷貝最快。如果這段數(shù)據(jù)要被存起來、跨函數(shù)傳遞、或者放進集合里長期持有那就直接存String用一次分配換掉整條鏈上的生命周期標注。這個取舍在下一節(jié)的實戰(zhàn)案例里會詳細展開。4. 智能指針編譯期賬本不夠用的時候4.1 Box、Rc、Arc、RefCell 各自解決什么問題所有權(quán)的默認模型是單一所有者加獨占可變這個模型覆蓋了大部分場景但確實有幾類需求它表達不了需要在堆上分配且大小在編譯期未知的遞歸類型、需要多個所有者共享同一份數(shù)據(jù)、需要在只有不可變引用的前提下修改內(nèi)容。這三種需求分別對應Box、Rc/Arc、Cell/RefCell。類型所有權(quán)模型線程安全運行時開銷典型場景BoxT獨占堆分配取決于 T一次分配遞歸結(jié)構(gòu)、trait 對象RcT共享非原子計數(shù)否每次克隆加減一單線程共享只讀數(shù)據(jù)ArcT共享原子計數(shù)是T: SendSync原子操作比 Rc 慢多線程共享CellT內(nèi)部可變按值替換否幾乎為零小 Copy 類型的可變狀態(tài)RefCellT內(nèi)部可變運行時借用檢查否借用標志位增減需要在 self 里改內(nèi)容選型的順序我一般是這樣的先問是不是遞歸類型或需要 trait 對象是就上Box再問是不是真的需要多個所有者如果只是讀取共享用Arc包只讀數(shù)據(jù)就夠了別急著上RefCell最后才問是不是需要在不可變引用下修改需要才用RefCell。很多人一上來就寫RcRefCellT其實八成場景用RcT或者干脆傳引用就能解決白白引入了運行時開銷和 panic 風險。4.2 Rc 加 RefCell 的代價具體在哪RcT的每次clone都要對引用計數(shù)做一次加一每次drop做一次減一減到零才釋放。這些操作在單線程里是普通的整數(shù)加減開銷很小但不為零。RefCellT則維護一個借用計數(shù)器borrow()時檢查當前有沒有可變借用有就 panicborrow_mut()時檢查計數(shù)器是不是零不是零也 panic。這兩個檢查都是運行時分支編譯器沒法優(yōu)化掉。更需要注意的是循環(huán)引用導致的內(nèi)存泄漏。兩個Rc互相指向引用計數(shù)永遠不會歸零內(nèi)存就漏了。標準解法是把其中一個方向改成Weakuse std::cell::RefCell; use std::rc::{Rc, Weak}; struct Node { value: i32, next: OptionRcRefCellNode, prev: OptionWeakRefCellNode, // 用 Weak 打破環(huán) } fn main() { let a Rc::new(RefCell::new(Node { value: 1, next: None, prev: None })); let b Rc::new(RefCell::new(Node { value: 2, next: None, prev: Some(Rc::downgrade(a)) })); a.borrow_mut().next Some(Rc::clone(b)); println!(a 的強引用數(shù): {}, Rc::strong_count(a)); println!(a 的弱引用數(shù): {}, Rc::weak_count(a)); }Weak不增加強引用計數(shù)升級成Rc的時候要調(diào)upgrade()返回Option因為目標可能已經(jīng)被釋放了。這個模式在雙向鏈表、樹結(jié)構(gòu)里都會用到我建議只要結(jié)構(gòu)里出現(xiàn)“指回去”的邊就默認用Weak不要等到內(nèi)存漲上去才回頭改。4.3 有時候該退一步換數(shù)據(jù)結(jié)構(gòu)而不是堆智能指針這是我踩過的最大的一個坑。早期寫一個圖結(jié)構(gòu)的處理邏輯習慣性地用RcRefCellNode表示每個節(jié)點節(jié)點之間互相引用。代碼能跑但性能很差而且一旦涉及并發(fā)就完全沒法用因為Rc根本不是Send。后來改成用VecNode存所有節(jié)點節(jié)點之間用usize索引互相引用性能提升非常明顯代碼也短了。struct Graph { nodes: VecNode, } struct Node { edges: Vecusize, // 索引而不是引用 }索引方案的代價是你得自己保證索引有效刪節(jié)點的時候要處理懸空索引。但它換來的是連續(xù)的堆布局、零引用計數(shù)開銷、天然的Send Sync而且序列化也簡單得多。我現(xiàn)在的判斷標準是如果一個數(shù)據(jù)結(jié)構(gòu)里RcRefCell出現(xiàn)超過兩處就該停下來想想是不是該用索引或者 arena 了。5. 一個真實場景的重構(gòu)從編譯不過到跑得穩(wěn)5.1 需求解析文本并緩存字段假設要寫一個小模塊從多行文本里解析出鍵值對緩存起來供后續(xù)查詢。第一版我圖省事直接讓結(jié)構(gòu)體持有輸入的切片struct Configa { entries: Vec(a str, a str), } impla Configa { fn parse(input: a str) - Self { let mut entries Vec::new(); for line in input.lines() { if let Some((k, v)) line.split_once() { entries.push((k.trim(), v.trim())); } } Config { entries } } fn get(self, key: str) - Optiona str { self.entries.iter().find(|(k, _)| *k key).map(|(_, v)| *v) } }這段代碼能編譯get返回的引用直接指向原始輸入零拷貝速度很快。問題出在調(diào)用方那邊一旦把input的所有權(quán)交出去或者input是函數(shù)內(nèi)部臨時構(gòu)造的String就出事了。5.2 第一版在真實調(diào)用鏈里崩了調(diào)用方大概是這樣的fn load() - Configstatic { let content std::fs::read_to_string(config.txt).unwrap(); Config::parse(content) // 報錯返回引用了局部變量 }編譯器報 E0515說不能返回指向局部變量的引用。這不是編譯器的刁難content在函數(shù)結(jié)束時就 drop 了返回的Config里那些指針會立刻變成懸垂指針。如果這段代碼在 C 里寫編譯能過運行時讀到的就是垃圾數(shù)據(jù)而且可能好幾個月都不出問題直到某次內(nèi)存布局變化才突然炸。第二版我把結(jié)構(gòu)體改成持有Stringstruct Config { entries: Vec(String, String), } impl Config { fn parse(input: str) - Self { let mut entries Vec::new(); for line in input.lines() { if let Some((k, v)) line.split_once() { entries.push((k.trim().to_string(), v.trim().to_string())); } } Config { entries } } fn get(self, key: str) - Optionstr { self.entries.iter().find(|(k, _)| k key).map(|(_, v)| v.as_str()) } }這樣寫能跨函數(shù)傳遞、能存進集合、能放進Arc里共享代價是每個鍵值對兩次堆分配。對于配置文件這種一次性加載、長期駐留的場景這個代價完全值得。但如果是解析大文件做流式處理每行兩次分配就有點浪費了。5.3 第三版用 Cow 做折中Cow寫時克隆是這兩者之間的折中方案。它在不需要修改的時候借用原始數(shù)據(jù)需要修改的時候才分配use std::borrow::Cow; enum Entrya { Borrowed(a str), Owned(String), } fn normalize(s: str) - Cow_, str { if s.contains(\t) { Cow::Owned(s.replace(\t, )) } else { Cow::Borrowed(s) } }Cowa, str是標準庫提供的枚舉只有Borrowed和Owned兩個變體。它的好處是調(diào)用方不用關心底層到底是借用還是擁有用.as_ref()或Deref就能當str用。壞處是它仍然帶著生命周期參數(shù)跨函數(shù)邊界的時候該傳播還得傳播而且枚舉本身占的?？臻g比單純的str大具體多大可以用size_of實測一下不同版本和優(yōu)化下會有差異。我現(xiàn)在的選擇順序是數(shù)據(jù)生命周期短、調(diào)用鏈淺用str加生命周期數(shù)據(jù)要被長期持有、跨線程傳遞用String兩者之間搖擺不定的中型場景用Cow。這個順序不是教條但你照著走能少走彎路。6. 高頻報錯與排查速查6.1 錯誤碼對照表被借用檢查器攔住的時候先看錯誤碼再看提示里的“誰的借用還沒結(jié)束”。下面這張表是我整理的高頻錯誤基本上覆蓋了日常八成的情況。錯誤碼含義典型改法E0382使用了已經(jīng) move 的值改傳引用或在轉(zhuǎn)移前 cloneE0499同一作用域內(nèi)兩次可變借用拆分成兩個階段或用索引代替引用E0502可變借用與不可變借用沖突先讀后寫或縮短不可變借用的生命周期E0505借用還沒結(jié)束就要 move讓借用先結(jié)束再 moveE0515返回了局部變量的引用返回擁有所有權(quán)的類型E0597被借用的值活不到那么久調(diào)整作用域順序或改為擁有E0716臨時值在借用期間被釋放先用 let 綁定成變量再借用E0106缺少生命周期標注按省略規(guī)則補上或改成擁有類型E0716 值得單獨提一句很多人寫過類似的代碼然后一臉茫然fn main() { // let s String::from(hello).as_str(); // 報錯 E0716 let tmp String::from(hello); // 先綁定成變量 let s tmp.as_str(); // 再借用 println!({}, s); }原因是String::from(hello)產(chǎn)生的臨時值在這一行結(jié)束時就被 drop 了as_str()借出來的引用立刻懸垂。先綁定到tmp之后tmp活到作用域結(jié)束借用才合法。這類問題的排查思路很統(tǒng)一看那個被借用的值是不是臨時值是就給它一個名字。6.2 排查順序先找誰借了誰再看誰要活多久我處理借用錯誤的固定流程是這樣的。第一步看錯誤提示里點名的變量確認是“值被 move 了”還是“借用沖突”。第二步如果是借用沖突從報錯位置往上找找最后一個使用這個引用的地方那里就是借用結(jié)束的位置。第三步如果想讓借用提前結(jié)束就把后面的寫操作挪到那之后或者把讀的結(jié)果先取出來存成獨立的值。第四步如果怎么調(diào)都不行說明數(shù)據(jù)結(jié)構(gòu)的所有權(quán)模型設計有問題考慮換成索引、Rc或者擁有類型。這個流程里第三步最常用。舉一個我經(jīng)常遇到的場景需要在HashMap里查一個值然后修改它use std::collections::HashMap; fn main() { let mut map: HashMapString, i32 HashMap::new(); map.insert(a.to_string(), 1); // let v map.get(a).unwrap(); // map.insert(b.to_string(), 2); // 報錯 E0502 // println!({}, v); let v map.get(a).copied().unwrap_or(0); // 先取值結(jié)束借用 map.insert(b.to_string(), 2); println!({}, v); }copied()把Optioni32變成Optioni32借用當場結(jié)束后面的插入就自由了。這個技巧在處理哈希表、緩存的時候特別好用我基本養(yǎng)成了習慣只要借出來的值很小且 Copy先拷貝再用。6.3 幾條踩出來的實操心得第一別怕加花括號。雖然 NLL 已經(jīng)聰明很多但在某些復雜表達式里顯式劃一個作用域讓借用提前結(jié)束比絞盡腦汁調(diào)整順序省事得多。第二clone()不是洪水猛獸在冷路徑上用 clone 換代碼清晰度是完全劃算的我反對的是在熱循環(huán)里無意識地 clone。第三遇到RcRefCellT的borrow_mutpanic先找有沒有在同一段代碼里同時持有兩個借用尤其是鏈式調(diào)用里臨時值還沒釋放的情況把中間結(jié)果用let綁定出來往往就好了。第四函數(shù)簽名優(yōu)先用借用只有在確實需要保存或跨線程的時候才用擁有類型這條規(guī)則能讓你的模塊接口干凈很多。第五如果一段邏輯里到處都是unsafe或者反射式的類型轉(zhuǎn)換那多半不是所有權(quán)的問題是數(shù)據(jù)結(jié)構(gòu)選錯了回頭看看第 4.3 節(jié)。關于內(nèi)存管理我個人在實際操作中最深的一點體會是所有權(quán)系統(tǒng)真正改變的不是你寫代碼的語法而是你設計數(shù)據(jù)結(jié)構(gòu)的方式。寫 C 的時候我會自然地想“這塊內(nèi)存誰 free”寫 Java 的時候基本不想寫 Rust 之后我會在動手寫第一行之前就想清楚“這個值的生命周期有多長、誰能改它、要不要共享”。這個思考前置的過程一開始很別扭習慣之后反而省掉了大量調(diào)試時間因為很多問題在敲代碼的時候就已經(jīng)被逼著想明白了。