計(jì)對比)
顯式閉包捕獲子句capture clause是 lambda 表達(dá)式中最容易被低估的部分。大多數(shù)開發(fā)者第一次接觸 lambda 時(shí)注意力都放在參數(shù)列表、返回類型和函數(shù)體上只有在編譯器報(bào)錯(cuò)、程序崩潰或出現(xiàn)“明明捕獲了變量卻拿到舊值”的詭異 bug 時(shí)才會回頭審視捕獲子句。實(shí)際項(xiàng)目里捕獲子句決定了閉包能訪問哪些外部變量、以什么方式訪問這些變量、是否延長對象生命周期以及閉包放到多線程或異步環(huán)境后是否安全。顯式閉包捕獲簡單說就是把“閉包到底捕獲了什么、怎么捕獲”清楚寫到語法里讓開發(fā)者主動聲明而不是完全依賴編譯器的隱式推斷。下面從語言設(shè)計(jì)的角度比較 C、Swift、Rust、Java、Kotlin 的典型做法再討論捕獲子句的核心權(quán)衡最后給出一套可落地的設(shè)計(jì)建議和工程檢查清單。1. 為什么顯式閉包捕獲子句需要精雕細(xì)琢1.1 閉包捕獲的本質(zhì)與隱式捕獲的問題閉包本質(zhì)上是函數(shù)對象除了函數(shù)簽名和函數(shù)體之外還自帶一份“環(huán)境”。環(huán)境里存放它引用的外部變量這些變量可能被復(fù)制一份也可能保存引用還可能發(fā)生所有權(quán)轉(zhuǎn)移。語言自身決定采用哪種策略就形成了不同的捕獲語義。隱式捕獲讓編譯器自動識別閉包體中使用的外部變量然后自行選擇捕獲方式。這種方式寫起來很簡潔但會帶來三類問題可讀性差。別人閱讀閉包體時(shí)無法一眼看出它依賴了哪些外部狀態(tài)。閉包體越長隱藏依賴越多。生命周期不可控。如果默認(rèn)按引用捕獲外部對象銷毀后再執(zhí)行閉包就會訪問懸空引用??勺冃圆煌该鳌S械拈]包會修改外部變量有的不會隱式捕獲會讓并發(fā)場景下的行為變得難以推理。用一段最小代碼對比int x 10; // 隱式捕獲編譯器自己去發(fā)現(xiàn) x auto f1 [] { return x; }; // 顯式捕獲聲明清楚只捕獲 x且按值捕獲 auto f2 [x] { return x; };兩個(gè)閉包在功能上一致但f2的捕獲列表一眼就能看明白只捕獲x并且按值捕獲。如果閉包體有幾十行隱式捕獲的“自動”就會變成“意外依賴”稍不留神就會把局部狀態(tài)、成員變量甚至臨時(shí)對象一起捕獲進(jìn)去。1.2 顯式捕獲需要承擔(dān)的四個(gè)職責(zé)好的顯式捕獲子句不應(yīng)該只是“把變量名寫一遍”它至少要承擔(dān)四項(xiàng)職責(zé)職責(zé)說明缺少時(shí)會怎樣列出捕獲變量閉包依賴哪些外部狀態(tài)必須可見隱藏依賴代碼審查困難指定捕獲方式區(qū)分按值、按引用、所有權(quán)轉(zhuǎn)移生命周期和性能不可控聲明生命周期策略處理 weak、unowned、借用關(guān)系循環(huán)引用、懸空引用暴露可變性語義讓調(diào)用者知道閉包是否會修改外部狀態(tài)并發(fā)下共享狀態(tài)被意外修改例如 Swift 中的捕獲列表[weak self]同時(shí)表達(dá)了“捕獲 self”和“不持有 self”兩層意思。C 中的[x std::move(obj)]則表達(dá)“把 obj 移動進(jìn)閉包原變量不再可用”。這些都屬于顯式捕獲設(shè)計(jì)的一部分。1.3 為什么還要討論“更優(yōu)設(shè)計(jì)”不同語言對“顯式”的粒度理解并不一致。C 的捕獲列表最豐富但默認(rèn)捕獲[]和[]仍然是整體捕獲顯式程度可以繼續(xù)提高。Swift 把捕獲列表放在參數(shù)列表前但對所有權(quán)、可變性的表達(dá)能力有限。Rust 依賴所有權(quán)系統(tǒng)保證安全卻缺少傳統(tǒng)意義上的捕獲列表語法只能通過move關(guān)鍵字控制所有權(quán)轉(zhuǎn)移。Java 干脆不允許自定義捕獲只允許捕獲 effectively final 變量。這些差異說明“顯式閉包捕獲”沒有一個(gè)絕對正確的答案它必須和語言的類型系統(tǒng)、生命周期規(guī)則、并發(fā)模型配合。理解這些差異后才能討論什么設(shè)計(jì)在當(dāng)前場景下更優(yōu)。2. 主流語言中的顯式閉包捕獲實(shí)現(xiàn)2.1 C功能最完整但也最容易踩坑C 從 C11 開始提供 lambda 表達(dá)式捕獲子句是一對中括號[]放在 lambda 開頭。C14 又加入初始化捕獲讓捕獲語法變得更靈活。int a 1; int b 2; auto f1 [a] { return a; }; // 按值捕獲 a auto f2 [a] { return a; }; // 按引用捕獲 a auto f3 [, b] { return a b; }; // 默認(rèn)按值捕獲b 按引用捕獲 auto f4 [x a * 2] { return x; }; // C14 初始化捕獲C 的捕獲方式非常豐富但也帶來兩個(gè)難點(diǎn)第一可變性需要額外用mutable聲明。按值捕獲的變量在 lambda 內(nèi)部默認(rèn)是const的如果想讓閉包內(nèi)部的自增操作生效必須寫成int n 0; auto counter [n]() mutable { return n; }; std::cout counter(); // 1 std::cout counter(); // 2 // 外部 n 仍然是 0第二默認(rèn)按引用捕獲極其危險(xiǎn)。下面這段代碼就是典型懸空引用std::functionint(int) make_adder(int base) { return [](int x) { return base x; }; }base是局部變量的引用函數(shù)返回后引用失效閉包繼續(xù)調(diào)用就會產(chǎn)生未定義行為。正確寫法是按值捕獲或使用智能指針把生命周期交給調(diào)用方管理。2.2 Swift捕獲列表里的 weak 與 unownedSwift 的閉包捕獲列表位于參數(shù)列表之前一組方括號放在閉包開頭。最典型的場景是處理self的循環(huán)引用。class ViewController { var data: [String] [] func load() { let closure { [weak self] in self?.data [] } } }[weak self]表示閉包對self持有弱引用不會造成循環(huán)引用。如果需要解包后長期使用可以寫成let closure { [weak self] in guard let self else { return } self.data [] }Swift 還支持[unowned self]語義是“不持有 self但假定 self 在閉包執(zhí)行時(shí)一定存在”。如果 self 已經(jīng)釋放調(diào)用閉包會直接崩潰。因此unowned適合生命周期強(qiáng)關(guān)聯(lián)的場景例如self持有閉包且閉包不會超過self生命周期的場景。除了 weak 和 unownedSwift 捕獲列表也能創(chuàng)建副本var count 0 let closure { [current count] in print(current) } count 10 closure() // 輸出 0而不是 10這種“顯式快照”能力在異步任務(wù)中非常有用。2.3 Rust所有權(quán)系統(tǒng)下的捕獲與 moveRust 的閉包默認(rèn)按借用捕獲變量編譯器根據(jù)閉包體的使用方式自動推斷Fn、FnMut還是FnOnce。如果需要強(qiáng)制按值捕獲必須使用move關(guān)鍵字let x String::from(hello); let f move || println!({}, x); // 此時(shí) x 已經(jīng)移動到閉包中move是一個(gè)整體捕獲控制它把所有捕獲到的變量按值轉(zhuǎn)移進(jìn)閉包。在 Rust 2021 中閉包支持部分移動捕獲可以從結(jié)構(gòu)體中只移動被使用的字段而不是整個(gè)結(jié)構(gòu)體。struct Data { name: String, id: u32, } let mut data Data { name: String::from(test), id: 1 }; let f move || { println!({}, data.name); };這段代碼只會移動data.namedata.id仍然可以被外部使用。相比 C 和 SwiftRust 沒有一個(gè)復(fù)雜的“捕獲列表”它用所有權(quán)系統(tǒng)把“捕獲后是否仍然可用”的問題交給編譯器判斷。代價(jià)是捕獲方式不夠直觀開發(fā)者必須理解借用和所有權(quán)規(guī)則。2.4 Java 與 Kotlin限制型捕獲Java 的 lambda 不能顯式寫捕獲列表只能捕獲 effectively final 變量。所謂 effectively final就是變量在初始化后不再被重新賦值。int x 10; Runnable r () - System.out.println(x); // 合法 x 11; // 編譯錯(cuò)誤x 不再是 effectively final這種設(shè)計(jì)避免了“l(fā)ambda 內(nèi)修改外部局部變量”的爭議但限制了表達(dá)力。如果需要修改計(jì)數(shù)只能使用AtomicInteger或數(shù)組容器。Kotlin 比 Java 寬松允許 lambda 捕獲可變變量并且可以修改var count 0 val increment { count } increment() println(count) // 1這里的捕獲是引用捕獲閉包共享同一個(gè)count變量。如果異步場景下捕獲了可變var就會產(chǎn)生競態(tài)。要模擬“快照捕獲”可以先把變量賦值給一個(gè)valvar count 0 val snapshot count val closure { println(snapshot) }2.5 主流語言捕獲設(shè)計(jì)對比語言捕獲子句位置捕獲方式可變性控制生命周期控制C[]位于參數(shù)前按值、按引用、初始化捕獲使用mutable依賴開發(fā)者容易懸空Swift[]位于參數(shù)前捕獲列表、weak、unowned、快照由閉包體決定weak/unowned 支持Rustmove關(guān)鍵字借用、所有權(quán)轉(zhuǎn)移通過Fntrait 自動推斷借用檢查器編譯期保證Java無值捕獲 effectively final只讀編譯器限制Kotlin無引用捕獲可變依賴開發(fā)者有競態(tài)風(fēng)險(xiǎn)3. 顯式捕獲設(shè)計(jì)中的四組關(guān)鍵權(quán)衡3.1 整體捕獲 vs 逐變量捕獲C 的[]和[]屬于整體捕獲優(yōu)點(diǎn)是一行代碼捕獲所有外部變量缺點(diǎn)是閉包體發(fā)生變化時(shí)捕獲集合也會隱式變化。重構(gòu)時(shí)很容易把一個(gè)本來不依賴的變量“順手”捕獲進(jìn)去。逐變量捕獲更安全但寫起來更繁瑣。[a, b]明確告訴讀者閉包只依賴a和b。更優(yōu)的設(shè)計(jì)不是完全禁止整體捕獲而是把整體捕獲作為顯式聲明而不是默認(rèn)行為。例如可以要求開發(fā)者必須寫[capture all by value]來表示“我確實(shí)要捕獲所有變量”并讓代碼審查工具對整體捕獲給出告警。3.2 默認(rèn)行為樂觀捕獲 vs 顯式聲明如果語言默認(rèn)隱式捕獲全部變量代碼寫起來很輕松但行為脆弱。Java 選擇了一個(gè)比較安全的默認(rèn)值只允許捕獲 effectively final 變量把“修改外部變量”這道門直接關(guān)閉。Swift 的閉包默認(rèn)可以隱式捕獲self這雖然方便卻很容易制造循環(huán)引用。更有參考價(jià)值的設(shè)計(jì)是默認(rèn)按值捕獲并且禁止隱式捕獲引用如果確實(shí)需要引用捕獲必須寫清楚by reference或borrow。這樣閉包的默認(rèn)行為是可預(yù)測的特殊行為需要主動聲明。3.3 可變性表達(dá)可變性是捕獲設(shè)計(jì)中容易被忽略的維度。C 用mutable修飾閉包對象Rust 通過FnMut表達(dá)“閉包會修改捕獲變量”Swift 則更依賴變量本身的類型。更優(yōu)的捕獲子句可以把“捕獲方式”和“可變性”放在同一層capture var x // x 按可變值捕獲 capture var ref y // y 按可變引用捕獲 capture let z // z 按不可變值捕獲這種寫法比mutable放在函數(shù)體附近更直觀。閱讀閉包開頭時(shí)開發(fā)者就能知道哪些捕獲變量會被修改避免在并發(fā)場景下誤用共享狀態(tài)。3.4 生命周期與所有權(quán)C 的引用捕獲無法在編譯期防止懸空引用只能依靠開發(fā)者自律和第三方工具。Swift 引入 weak/unowned 打破循環(huán)引用但 unowned 使用不當(dāng)仍然會崩潰。Rust 把生命周期檢查放入類型系統(tǒng)在編譯期就拒絕“引用可能懸空”的程序。設(shè)計(jì)更優(yōu)捕獲語法時(shí)應(yīng)該優(yōu)先讓類型系統(tǒng)接管生命周期而不是靠注釋。一個(gè)捕獲子句如果能寫成capture borrowed value編譯器就能檢查借用是否超出被引用對象的生命周期如果寫成capture owned value編譯器就能明確閉包擁有該資源的所有權(quán)。這些權(quán)衡沒有標(biāo)準(zhǔn)答案關(guān)鍵是在“語法負(fù)擔(dān)”和“安全性”之間找到平衡。對庫作者和語言設(shè)計(jì)者來說捕獲子句的語法負(fù)擔(dān)應(yīng)當(dāng)與它解決的問題等級匹配。普通小閉包寫起來太累會讓人繞開語法危險(xiǎn)閉包寫起來太輕松又會埋下隱患。4. 從工程實(shí)踐反推“更優(yōu)設(shè)計(jì)”的方向4.1 捕獲列表應(yīng)該像參數(shù)列表一樣清晰參數(shù)列表是函數(shù)的“顯式輸入”捕獲列表則更像是閉包的“隱性輸入”。好的捕獲列表應(yīng)該和參數(shù)列表一樣容易被檢查。如果閉包捕獲了 5 個(gè)以上變量通常不是捕獲語法的問題而是這個(gè)閉包承擔(dān)的職責(zé)太重。這種情況下應(yīng)當(dāng)考慮把閉包抽取成命名函數(shù)或者把多個(gè)捕獲變量封裝成一個(gè)對象。實(shí)際編碼中可以用這個(gè)標(biāo)準(zhǔn)衡量捕獲子句是否合格只閱讀捕獲列表不閱讀閉包體能否判斷這個(gè)閉包訪問了哪些外部狀態(tài)如果不能說明捕獲設(shè)計(jì)還不夠顯式。4.2 讓類型系統(tǒng)接管生命周期而不是交給注釋C 項(xiàng)目中經(jīng)常能看到這樣的注釋“不要在函數(shù)返回后使用這個(gè)閉包”。這種注釋在評審時(shí)很容易被忽略。更可靠的做法是在語法層面讓編譯器拒絕錯(cuò)誤用法。Rust 就是一個(gè)例子它不允許閉包持有一個(gè)即將失效的引用因此這類 bug 在編譯期就被發(fā)現(xiàn)了。如果無法立即切換到 Rust也可以在生產(chǎn)代碼里用工程規(guī)范模擬C 項(xiàng)目禁用[]要求逐變量捕獲Swift 項(xiàng)目要求涉及self的閉包必須寫[weak self]Kotlin 項(xiàng)目在異步任務(wù)中禁止捕獲可變var。這些規(guī)則不一定需要語言支持代碼審查和靜態(tài)檢查工具也能執(zhí)行。4.3 為異步與并發(fā)準(zhǔn)備顯式語義異步代碼中閉包經(jīng)常被延后執(zhí)行捕獲變量時(shí)的上下文和實(shí)際執(zhí)行時(shí)的上下文可能完全不同。捕獲子句必須能夠表達(dá)“這個(gè)變量是快照還是共享引用”。例如 Swift 的Task { [weak self] in ... }在派發(fā)異步任務(wù)時(shí)顯式聲明了對self的持有方式。Rust 的async move則把所有權(quán)移入異步塊讓異步任務(wù)擁有完整的生命周期。更優(yōu)的捕獲設(shè)計(jì)應(yīng)該與 async/await 或協(xié)程模型結(jié)合讓開發(fā)者一眼看出異步閉包是否延長了外部對象的生命周期以及它是否會修改共享狀態(tài)。4.4 工程實(shí)踐中可以立即執(zhí)行的檢查清單下面的清單可以用于代碼評審也可以用于日常自檢不使用默認(rèn)整體捕獲每個(gè)捕獲變量都顯式列出。捕獲引用時(shí)確認(rèn)被引用對象的生命周期覆蓋閉包的最晚執(zhí)行時(shí)間。涉及self、this或其他可能形成循環(huán)引用的對象時(shí)優(yōu)先使用弱引用。不捕獲可變的共享狀態(tài)除非已經(jīng)明確加鎖或使用原子類型。捕獲大對象時(shí)確認(rèn)是按值復(fù)制還是按引用借用避免無意識的高昂復(fù)制成本。把捕獲列表當(dāng)作閉包 API 的一部分來 review而不是把它當(dāng)作實(shí)現(xiàn)細(xì)節(jié)。這份清單在不同語言里落地方式略有差異但核心目標(biāo)一致讓每一個(gè)捕獲決策都經(jīng)過思考。5. 一份可落地的捕獲子句設(shè)計(jì)建議5.1 推薦語法形式這里給出一個(gè)示意性的偽語法用于展示“更優(yōu)設(shè)計(jì)”可以長成什么樣。它不直接對應(yīng)某種已發(fā)布語言而是把前面討論的職責(zé)集中在一起closure [ capture value x, capture ref y, capture weak owner, capture owned file, default by value ] (param: Int) - Int { return x param }設(shè)計(jì)要點(diǎn)capture value x按值復(fù)制x外部后續(xù)修改不影響閉包內(nèi)快照。capture ref y按引用借用y由編譯器檢查生命周期。capture weak owner弱引用捕獲不增加引用計(jì)數(shù)。capture owned file所有權(quán)轉(zhuǎn)移閉包持有file外部不能再使用。default by value兜底策略未列出的變量默認(rèn)按值捕獲。這個(gè)語法比 C 的[]更清晰比 Swift 的捕獲列表多了顯式的ref和owned也比 Rust 的move更精確。5.2 捕獲方式速查表捕獲方式語義適用場景主要危險(xiǎn)點(diǎn)value拷貝快照只讀數(shù)據(jù)、延遲讀取大對象復(fù)制開銷ref借用/引用短生命周期訪問懸空引用weak弱引用不持有回調(diào)、代理、異步任務(wù)需要解包可能為空owned所有權(quán)轉(zhuǎn)移任務(wù)執(zhí)行、資源管理原變量不再可用實(shí)際項(xiàng)目中可以把這張表作為設(shè)計(jì)討論的依據(jù)。選擇捕獲方式時(shí)先回答三個(gè)問題這個(gè)變量需要存活多久閉包會不會修改它原作用域還需要繼續(xù)使用它嗎5.3 把設(shè)計(jì)思路映射到現(xiàn)有語言如果沒有條件發(fā)明新語法可以把這套思路映射到主流語言C用[x]替代[]用[x std::move(obj)]表達(dá)所有權(quán)轉(zhuǎn)移避免裸的[]。Swift捕獲列表顯式寫出weak self需要快照時(shí)使用[count count]。Rust用move表達(dá)所有權(quán)轉(zhuǎn)移通過 trait bound 約束FnOnce和FnMut讓捕獲語義更明確。Java優(yōu)先使用 effectively final 變量需要修改時(shí)使用AtomicInteger等原子類型。Kotlin異步閉包中避免捕獲可變var需要快照時(shí)先賦值給val。這些做法不需要改語言只要在工程規(guī)范中堅(jiān)持就能獲得顯式捕獲的大部分收益。5.4 常見坑與處理方案第一類問題是 C 的默認(rèn)引用捕獲?,F(xiàn)象是函數(shù)返回后閉包仍然被調(diào)用結(jié)果變成隨機(jī)值或直接崩潰。原因是局部變量生命周期結(jié)束引用懸空。檢查方式是用 AddressSanitizer 跑一遍測試或者人工審查每個(gè)[]。解決方法是在捕獲列表中逐項(xiàng)寫出引用并確保引用目標(biāo)生命周期足夠長。第二類問題是 Swift 的[unowned self]使用不當(dāng)?,F(xiàn)象是閉包執(zhí)行時(shí)崩潰報(bào)EXC_BAD_ACCESS。原因是self已經(jīng)被釋放但unowned不保證生命周期。檢查方式是在崩潰日志中定位閉包捕獲列表。解決方法是改成[weak self]并在閉包內(nèi)用guard let self解包。第三類問題是 Kotlin 異步捕獲可變var?,F(xiàn)象是并發(fā)執(zhí)行時(shí)數(shù)據(jù)不一致難以復(fù)現(xiàn)。原因是閉包捕獲的是共享引用多個(gè)協(xié)程同時(shí)修改同一個(gè)變量。檢查方式是審查閉包捕獲列表查找被異步調(diào)用的 lambda 是否引用var。解決方法是把var轉(zhuǎn)成不可變的val快照或者使用線程安全的集合和原子類型。第四類問題是 Rust 中move捕獲導(dǎo)致原變量不可用。現(xiàn)象是編譯錯(cuò)誤提示變量已被 moved。原因是閉包整體捕獲了整個(gè)變量。解決方法是使用 Rust 2021 的部分移動捕獲或者只移動需要的字段。6. 常見問題排查與進(jìn)一步思考6.1 從錯(cuò)誤信息反推捕獲問題錯(cuò)誤現(xiàn)象可能原因檢查方式處理建議編譯期提示變量未被捕獲閉包體使用了外部變量但捕獲列表漏寫查看編譯器錯(cuò)誤位置在捕獲列表中加入該變量編譯期提示捕獲了不可用變量生命周期約束或所有權(quán)移動導(dǎo)致變量失效查看 owned/borrow 狀態(tài)使用引用或調(diào)整所有權(quán)轉(zhuǎn)移策略閉包執(zhí)行結(jié)果隨機(jī)或崩潰捕獲了超出生命周期的引用AddressSanitizer 或核心轉(zhuǎn)儲分析改成按值捕獲或延長生命周期Swift 閉包執(zhí)行崩潰unowned self生命周期判斷錯(cuò)誤查看崩潰棧改用weak self異步數(shù)據(jù)不一致捕獲了共享可變狀態(tài)審查閉包捕獲列表改為快照或加鎖Java 編譯錯(cuò)誤not effectively finallambda 內(nèi)修改了局部變量查看編譯器提示使用原子類型或重新設(shè)計(jì)結(jié)構(gòu)6.2 捕獲相關(guān)問題排查鏈路遇到捕獲相關(guān)問題時(shí)建議按以下順序排查先看捕獲列表閉包顯式捕獲了哪些變量是不是漏掉了必要變量再看生命周期被捕獲的引用是否能活到閉包最晚執(zhí)行時(shí)間然后看可變性閉包會修改哪些共享狀態(tài)這些修改是否安全最后看線程模型閉包在哪個(gè)線程執(zhí)行是否存在并發(fā)讀寫這個(gè)順序從具體到抽象能夠快速定位大多數(shù)捕獲問題。6.3 擴(kuò)展思考為協(xié)程和 actor 設(shè)計(jì)捕獲隨著異步編程成為默認(rèn)捕獲子句的設(shè)計(jì)也越來越重要。在協(xié)程模型中閉包可能被掛起、恢復(fù)、切換線程捕獲的變量必須能在多次執(zhí)行之間保持一致。actor 模型則要求捕獲不能把可變狀態(tài)“偷渡”到 actor 外部。更優(yōu)的捕獲設(shè)計(jì)應(yīng)當(dāng)與結(jié)構(gòu)化并發(fā)結(jié)合。例如任務(wù)啟動時(shí)顯式聲明“我拿走了什么、以什么方式拿走”任務(wù)結(jié)束時(shí)統(tǒng)一處理資源釋放編譯器和運(yùn)行時(shí)協(xié)作檢查捕獲變量的跨線程安全性。相比單純增加語法關(guān)鍵字這可能是更本質(zhì)的改進(jìn)方向。6.4 對開發(fā)者的練習(xí)建議如果當(dāng)前項(xiàng)目已經(jīng)有大量 lambda 或閉包可以安排一次“捕獲列表審計(jì)”。任務(wù)很簡單把所有隱式捕獲改成顯式捕獲然后記錄暴露出來的問題。C 項(xiàng)目搜索[]和[]逐個(gè)替換為逐變量捕獲。Swift 項(xiàng)目檢查所有閉包的捕獲列表為涉及self的閉包補(bǔ)上[weak self]。Kotlin 項(xiàng)目審查異步 lambda 是否捕獲了可變var。這個(gè)練習(xí)不需要修改業(yè)務(wù)邏輯卻會迫使開發(fā)者重新思考每一次捕獲決策。往往一次審計(jì)過后項(xiàng)目中隱藏的懸空引用、循環(huán)引用和共享狀態(tài)競態(tài)問題就會暴露出來。顯式閉包捕獲子句的設(shè)計(jì)本質(zhì)上是在可讀性、安全性和語法負(fù)擔(dān)之間尋找平衡。真正重要的不是發(fā)明一種新語法而是讓開發(fā)者在寫每一個(gè)閉包時(shí)都想清楚它依賴了哪些外部狀態(tài)、以什么方式持有這些狀態(tài)、這些狀態(tài)能活多久。如果下次寫代碼時(shí)想用 C 的[]或者想省略 Swift 的捕獲列表可以先停下來問自己一個(gè)問題這個(gè)閉包真的需要把整個(gè)上下文都拖進(jìn)來嗎把這個(gè)問題回答清楚閉包的設(shè)計(jì)就已經(jīng)成功了一半。